Description of problem:
It looks that when shutting down a system a script /etc/rc.d/init.d/killall
is supposed to run last after everything was stopped doing
a final sweep for strays. Only it appears that with an upstart
scheme it does not wait and it races with other scripts producing
on a screen messages like
/etc/rc6.d/S00killall: line 16: 2743 Terminated /etc/init.d/$subsys stop
If that is a purely cosmetic issue then the above can be prevented
by redirecting all stdout and stderr output of 'for ... ; done' loop
in that script to /dev/null. OTOH as this is racing, as indicated
by those error messages, then what are guarantees that something
would not be stopped too early? 'killall' is not doing any checks
(with this exception that it will not touch 'network').
Other possibility could be a removal but the script may turn out
to be really handy when one would want to get something close
to a real single-user mode.
Version-Release number of selected component (if applicable):
on every shutdown
Created attachment 301544 [details]
Fixes this bug. /etc/init.d/sshd kills itself via killall sshd.
Add trap '' TERM before the killall and trap TERM after.
component should be changed to openssh
> component should be changed to openssh
Is this truly the whole problem or you found (thanks!) one instance
where right now this is causing hiccups? 'killall' really used to
run as a final check and this does not seem to be the case anymore.
I put set -xv at front of /etc/init.d/killall and found that this is the script
that causes all of the "stopping <subsys> ... [ OK ]" messages on the console.
/usr/bin/killall is a completely different thing but it was related --
/etc/init.d/sshd wanted to kill /usr/sbin/sshd, but /usr/bin/killall kills the
script as well as any extra sshd's. Seems to me I remember a bug just like this
circa Solaris 2.5 ...
The error message is somewhat misleading. It wasn't line 16, but line 16 is the
beginning of the compound statement where the 'terminated' status code came
back, and /etc/init.d/$subsys stop was the text of the line which got the bad
status. When I changed that to bash -xv /etc/init.d/$subsys, the problem
confusingly went away (since the process named bash, not sshd).
> /usr/bin/killall is a completely different thing ...
Yes, I know. Maybe I should be more carefull but I thought that
from the context it was clear that we are talking about killall in
/etc/init.d/. See also a title for this bug report.
The comment about "there shouldn't be any" at the top of /etc/init.d/killall is
no longer accurate and should be revised. That script is part of the
initscripts rpm. (Or else if things were supposed to have been stopped by the
Knn links in /etc/init.d/rc6.d/ then there is a bug in upstart or something like
that. /etc/init.d/rc6.d/S00killall used to run after the Knn scripts IIRC.)
Actually, it does sound like there is a bug, because killall kills subsystems in
alphabetical order, not in the order specified by the Knn symbolic links.
Probably need a new bug for that...
I have patched the sshd init script in rawhide.