Description of problem: When shutting down the system we can see the following message: "Stopping avahi-daemon: Shutting down Avahi daemon: " because of a bug in /etc/rc.d/rc script. Version-Release number of selected component (if applicable): initscripts-8.31.2-1 How reproducible: Always Steps to Reproduce: 1. shut down the system 2. look at the shutdown messages on the screen Actual results: "Stopping avahi-daemon: Shutting down Avahi daemon: " Expected results: "Shutting down Avahi daemon: " Additional info: The bug is contained on lines 59-63 of "/etc/rc.d/rc" script: # Bring the subsystem down. if LC_ALL=C egrep -q "(killproc |action )" $i ; then $i stop else action $"Stopping $subsys: " $i stop fi Since avahi-daemon script has neither "killproc" nor "action" words, it gets called with "Stopping $subsys: " argument, which cause the duplicates messages.
A similar problem happens when starting readahead and readahead_early since they don't contain any of the words grepped for in order to not display a (redundant in this case) "Starting foo" line : if LC_ALL=C egrep -q "(daemon |action |success |failure )" $i 2>/dev/nul l \ || [ "$subsys" = "single" -o "$subsys" = "local" ]; then $i start else action $"Starting $subsys: " $i start fi
*** Bug 187099 has been marked as a duplicate of this bug. ***
FWIW, on a typical FC development install, I've checked which scripts where affected (by modifying rc), and found only : - readahead_early (on start) - readahead (on start) - ahavi (on stop) - killall (on stop) For killall, it would be trivial to add some simple output to it. It also seems to contain some legacy code regarding the check for $subsys.init files, since AFAICS there are no files named like that in Fedora Core.
Created attachment 131743 [details] Patch to rc that removes echo lines for starting and stopping services This is a suggested patch : - Removes "action $"Stopping $subsys: "", leave it up to the init scripts. - Removes "action $"Starting $subsys: "", leave it up to the init scripts. - Don't check /var/lock/subsys/$subsys.init files, only without ".init" - Minor spaces vs. tabs cleanup.
BTW, this kind of change would also fix bug #110761 it seems.
And yet another reference : bug #161470 is also about the same problem.
So the reason this is this way is that by checking for 'daemon' and similar functions, we make sure that scripts that don't use /etc/init.d/functions specific things are wrapped properly, have similar output, etc. In the old initlog days, it made sure they got logged too. So, we could either: - check for the entirerty of our exported function space - do what you suggest, and just let things that don't call success/failure look different
Well in this case, it's causing more trouble with Fedora and Red Hat scripts than it is helping them, since they're not the ones these exceptions are meant to "fix" in the first place. If the idea is to give the user at least a hint that the ugly script he dropped manually in /etc/rc.d/init.d/ (which might even halt booting up if it's not properly made...) is getting started/stopped, then maybe the grep could check for "/etc/init.d/functions" (hum, or "/etc/rc.d/init.d/functions"...) and decide based on that? Then if the script sources "functions" but doesn't manage its own output, we consider it broken, period. I really can't recall the last time I met an init script that didn't take care of its own "Starting", "Stopping" etc. output. That's why my own preference would be to scratch all the exceptions cases. No srong feelings though, as long as the hacks stop breaking the proper init scripts, which is why this is to be considered a bug in the first place.
Any decision yet? How about the option of checking for "/etc/init.d/functions" or "/etc/rc.d/init.d/functions" in the init script? Since any script sourceing that file is likely to use the functions it provides, (uglier) "custom" scripts that entirely manage (or disable) their own output probably won't be sourceing it, right?
Probably makes more sense than grepping for action, yes. Or we could just let custom scripts be ugly.
I'm all for letting custom scripts be ugly. We can't fix what we don't ship anyway, so keeping things simple seems to make most sense here.
Hm, I should see how this would interact if we need to bring something like initlog back.
Created attachment 132996 [details] Patch to rc Here is a new version of the patch, which checks for "init.d/functions" (thus both /etc/rc.d/init.d and /etc/init.d variants are cought) instead of some of its function names. This seems like the cleanest way of fixing the problem. Note : The "single" script sources the functions file. The ones that don't are "single" and "killall", so I've also changed that. This means no more weird "Starting killall:" output either, as it seemed to make very little sense.
Argh, I really would have likeed to see this change go into yesterday's initscript 8.38 release. Bill, what do you think about the last patch? Is there any problem with it?
Will look at it today along with poking initlog.
Bill, I saw that you released initscripts 8.39 yesterday. As we are now post test3 and approaching FC6 final, would you consider at least including the simple fix to rc in order to avoid the messages printed twice, even if you don't have time to poke initlog as much as you'd like?
And 8.41 went by. Please, oh, please? Maybe everyone else uses rhgb... but for text mode boot, it's ugly.
Something along those lines added in CVS.