Red Hat Bugzilla – Bug 102777
init does not execute all kill scripts when changing run levels
Last modified: 2014-03-16 22:38:13 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
Apparently when changing run levels, init will only run kill scripts whose
process name matches the service name. The problem can easily be observed in
numerous versions of Red Hat Linux... at least 9, 8, and 7.3.
One easy example can be observed with Spam Assassin (in RHL 9). The service
name is 'spamassassin', but the process name is 'spamd'.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. chkconfig --level 2 spamassasin on
2. boot into run level 2
3. use 'ps ax' to witness spamd running
4. execute 'telinit 1' to drop to run level 1
5. use 'ps ax' again to witness spamd is still running despite the presence of
6. make the service name match by 'cp /etc/init.d/spamassassin /etc/init.d/spamd'
7. chkconfig --del spamassassin; chkconfig --add spamd
8. repeat steps 2 through 4
9. notice the spamd is not running
Actual Results: After step 5, spamd remains running although most all other
services have been shutdown. There's no mention of spamassassin being shutdown.
After step 8, spamd gets stopped as one would expect.
Expected Results: After step 5, spamd should have been shutdown. Same goes for
any other process whose process name is not the same as the service name and has
a corresponding kill script in the run level being switch to.
Debugging messages in the service script show that the service script is never
called at all. Google searches on this problem show that init tries to be
efficient by not stopping processes that are already stopped (or starting those
already started). Oddly enough, this problem doesn't seem to affect start
scripts in the same way.
It would be very desirable to have service names that don't necessarily match
the process name. For example, I have numerous Progress databases where each
can be brought up/down via the 'service' command. Since the database server
process is the same for every database, the service name needs to be unique to
distinguish which database is to be affected by the 'service' command.
This is a bug in the init script. lockfiles created in /var/lock/subsys must
match the script name. Process name isn't relevant.
Thanks Bill. I've changed my init service scripts to conditionally create
/var/lock/subsys lock files (whose name matches the service name, i.e., database
name) much like how the crond service script does and the kill scripts are now
working as desired.