Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 190989 - Stopping avahi-daemon message printed twice
Summary: Stopping avahi-daemon message printed twice
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
: 187099 (view as bug list)
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2006-05-07 21:44 UTC by petrosyan
Modified: 2014-03-17 02:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-09-21 17:20:37 UTC

Attachments (Terms of Use)
Patch to rc that removes echo lines for starting and stopping services (deleted)
2006-06-29 12:46 UTC, Matthias Saou
no flags Details | Diff
Patch to rc (deleted)
2006-07-25 15:23 UTC, Matthias Saou
no flags Details | Diff

Description petrosyan 2006-05-07 21:44:50 UTC
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):

How reproducible:

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
		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.

Comment 1 Matthias Saou 2006-06-21 16:38:27 UTC
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
                action $"Starting $subsys: " $i start

Comment 2 Karel Zak 2006-06-22 19:16:14 UTC
*** Bug 187099 has been marked as a duplicate of this bug. ***

Comment 3 Matthias Saou 2006-06-23 09:26:08 UTC
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.

Comment 4 Matthias Saou 2006-06-29 12:46:57 UTC
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.

Comment 5 Matthias Saou 2006-06-29 13:01:50 UTC
BTW, this kind of change would also fix bug #110761 it seems.

Comment 6 Matthias Saou 2006-06-29 13:06:15 UTC
And yet another reference : bug #161470 is also about the same problem.

Comment 7 Bill Nottingham 2006-06-29 21:11:53 UTC
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

Comment 8 Matthias Saou 2006-06-30 09:47:31 UTC
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.

Comment 9 Matthias Saou 2006-07-04 23:40:34 UTC
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?

Comment 10 Bill Nottingham 2006-07-05 17:44:47 UTC
Probably makes more sense than grepping for action, yes. Or we could just let
custom scripts be ugly.

Comment 11 Matthias Saou 2006-07-10 09:38:02 UTC
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.

Comment 12 Bill Nottingham 2006-07-10 19:45:13 UTC
Hm, I should see how this would interact if we need to bring something like
initlog back.

Comment 13 Matthias Saou 2006-07-25 15:23:17 UTC
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.

Comment 14 Matthias Saou 2006-08-02 09:54:52 UTC
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?

Comment 15 Bill Nottingham 2006-08-02 14:13:36 UTC
Will look at it today along with poking initlog.

Comment 16 Matthias Saou 2006-09-06 11:01:19 UTC
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?

Comment 17 Matthias Saou 2006-09-20 15:58:28 UTC
And 8.41 went by. Please, oh, please?

Maybe everyone else uses rhgb... but for text mode boot, it's ugly.

Comment 18 Bill Nottingham 2006-09-21 17:20:37 UTC
Something along those lines added in CVS.

Note You need to log in before you can comment on or make changes to this bug.