Bug 173049 - chkconfig does not create K* symlinks in the same directories as the S* symlinks
chkconfig does not create K* symlinks in the same directories as the S* symlinks
Product: Fedora
Classification: Fedora
Component: hplip (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2005-11-12 22:58 EST by Reuben Farrelly
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-10 07:40:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Reuben Farrelly 2005-11-12 22:58:32 EST
My understanding of how the SysVinit scripts work is that an S* symlink is
executed when the runlevel is entered, and a K symlink is executed to stop the
service when the runlevel is left.

However this does not seem to be the way that chkconfig-1.3.23-1 is working
right now.  The S runlevel symlink is set up correctly, but no corresponding K
symlink is set up in the same runlevel directory for when leaving the runlevel.

A good example of a package in core is the hplip.  I have recently installed it
and even rerun chkconfig against it, and now booting into runlevel 3, and then
init 1 down to runlevel one leaves this package running (the script is never
called to stop the service), because no K symlink has been created to kill it
when exiting runlevel 3.
Comment 1 Robert Scheck 2005-11-13 07:04:30 EST
Maybe your understanding isn't correct, maybe mine isn't. Let's take the 
following example:

lrwxrwxrwx 1 root root   12 30. Jan 2005  rc0.d/K90hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 30. Jan 2005  rc1.d/K90hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 30. Jan 2005  rc2.d/K90hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 18. Sep 14:20 rc3.d/S01hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 30. Jan 2005  rc4.d/K90hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 18. Sep 14:20 rc5.d/S01hp -> ../init.d/hplip
lrwxrwxrwx 1 root root   12 30. Jan 2005  rc6.d/K90hp -> ../init.d/hplip

When entering runlevel 3 hplip is started, when switching to runlevel 1 it
is killed. Not the same runlevel has to provide the K symlink, but the other 
runlevels, where the daemon shouldn't run.

Maybe creating the K symlinks or the hplip initscript is broken in latest 
rawhide, but I didn't notice this, yet. Otherwise I can't see any problems 
Comment 2 Reuben Farrelly 2005-11-13 08:24:52 EST
Ok the problem is that I have the same symlinks as you - but for moving from RL3
to RL1 the K90hplip does not seem to be executed.  However I can manually run
"../init.d/hplip stop" and it stops as you'd expect, so it may be a problem with
the hplip initscript (and the hplip initscript is best describe as ...
'different' to the norm).  In that case I guess we could reassign this from
chkconfig to the hplip package..

There is plenty of information about starting services in runlevels but
relatively little about stopping services, although a few that I have seen do
state that a corresponding K should be run when exiting a given runlevel.

I also have a couple of other scripts which behave in the same way but hplip is
a good example :)
Comment 3 Reuben Farrelly 2005-11-13 08:34:34 EST
Looks like you are correct, Robert.  I just came across this document by Miquel
van Smoorenberg where he states that:

   When one switches from (for example) runlevel 2 to runlevel 3,
   /etc/init.d/rc will first execute in alphabetical order all K
   scripts for runlevel 3 (/etc/rc3.d/KXXxxxx) with as first argument
   "stop" and then all S scripts for runlevel 3 (/etc/rc3.d/SXXxxxx)
   with as first argument "start".


Which also means there is a bit of wrong documentation out there on the net ;-)

Reassigning this to hplip now since it looks like an hplip bug........
Comment 4 Tim Waugh 2005-11-15 05:06:48 EST
Can you explain in more detail what the hplip bug is?  I don't see anything
wrong in current rawhide.  Each runlevel has either K10hplip or S50hplip.
Comment 5 Reuben Farrelly 2005-11-15 05:12:16 EST
Yes, go from runlevel 3, down to runlevel 1, via 'init 1'.

For me, the hplip service is not shut down - neither the init script called with
the 'stop' argument, executed, and the hplip service is kept running.

It's a fairly low priority bug, I think.....
Comment 6 Stephen Warren 2005-12-18 02:47:28 EST
I get this too. Assuming I'm in runlevel 3, and run "telinit 5", I get this message:

Starting hpssd: can't lock /var/run/hpssd.pid, running daemon's pid may be 2341


[swarren@esk ~]$ chkconfig --list hplip
hplip           0:off   1:off   2:on    3:on    4:on    5:on    6:off
[swarren@esk ~]$ find /etc/rc.d |grep hplip

This seems to affect Avahi too, because I also get this message on the runlevel

Starting Avahi daemon... Daemon already running on PID 2504
Comment 7 Tim Waugh 2006-01-05 06:37:14 EST
This might be fixed by the patch in bug #176966.  Does hplip-0.9.7-7 still do this?
Comment 8 Stephen Warren 2006-01-06 12:44:33 EST
These messages seem to be fixed with hplip-0.9.7-7.

If I do this manually:

    service start hplip
    service start hplip

I do get this message:

    Starting hpssd: can't lock /var/run/hpssd.pid, running daemon's pid may be 3618

I don't know if this is normal if you attempt to start an already-started
service though...
Comment 9 Stephen Warren 2006-01-06 12:45:20 EST
Oh, I still get the Avahi message though... Is that normal? Should I file a
separate bug report for that?
Comment 10 Tim Waugh 2006-01-06 12:47:42 EST
The avahi message certainly needs a separate bug report, yes, against avahi.
Comment 11 Reuben Farrelly 2006-01-06 17:15:29 EST
twaugh: yes the part of the which I initially reported is now fixed.  The two
services do now shut down when going to RL1.

I'll leave it for you to close if you're happy with it - thinking particularly
about comment #8, although failing to start like that is the intended behaviour
I think?
Comment 12 Tim Waugh 2006-01-10 07:40:01 EST
Yes, that's fine I think.

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