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.

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.

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?

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.

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?