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): SysVinit-2.84-13 How reproducible: Always 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 /etc/rc1.d/K30spamassassin 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. Additional info: 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.