Bug 102777 - init does not execute all kill scripts when changing run levels
Summary: init does not execute all kill scripts when changing run levels
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: SysVinit   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-20 21:15 UTC by John Florian
Modified: 2014-03-17 02:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-20 21:20:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Florian 2003-08-20 21:15:59 UTC
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):

How reproducible:

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.

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.

Comment 1 Bill Nottingham 2003-08-20 21:20:24 UTC
This is a bug in the init script. lockfiles created in /var/lock/subsys must
match the script name. Process name isn't relevant.

Comment 2 John Florian 2003-08-21 14:18:09 UTC
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.

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