Red Hat Bugzilla – Bug 190989
Stopping avahi-daemon message printed twice
Last modified: 2014-03-16 22:59:39 EDT
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):
Steps to Reproduce:
1. shut down the system
2. look at the shutdown messages on the screen
"Stopping avahi-daemon: Shutting down Avahi daemon: "
"Shutting down Avahi daemon: "
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
action $"Stopping $subsys: " $i stop
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
|| [ "$subsys" = "single" -o "$subsys" = "local" ]; then
action $"Starting $subsys: " $i start
*** 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
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
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.