Bug 173049

Summary: chkconfig does not create K* symlinks in the same directories as the S* symlinks
Product: [Fedora] Fedora Reporter: Reuben Farrelly <reuben-redhatbugzilla>
Component: hplipAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: redhat-bugzilla, swarren-tag-rhbugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-10 12:40:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Reuben Farrelly 2005-11-13 03:58:32 UTC
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 12:04:30 UTC
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 
there.

Comment 2 Reuben Farrelly 2005-11-13 13:24:52 UTC
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 13:34:34 UTC
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".

http://groups.google.com/group/linux.debian.devel/tree/browse_frm/thread/e9befc62835fd227/0ae82096a398a6c0?rnum=11&q=SysVinit+runlevel+K&_done=%2Fgroup%2Flinux.debian.devel%2Fbrowse_frm%2Fthread%2Fe9befc62835fd227%2Fbd943a0dbc115dae%3Flnk%3Dst%26q%3DSysVinit+runlevel+K%26rnum%3D1%26#doc_7371177371ea2ebb

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 10:06:48 UTC
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 10:12:16 UTC
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 07:47:28 UTC
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
                                                           [FAILED]

Note:

[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
/etc/rc.d/rc0.d/K10hplip
/etc/rc.d/rc1.d/K10hplip
/etc/rc.d/rc2.d/S50hplip
/etc/rc.d/rc3.d/S50hplip
/etc/rc.d/rc4.d/S50hplip
/etc/rc.d/rc5.d/S50hplip
/etc/rc.d/rc6.d/K10hplip
/etc/rc.d/init.d/hplip

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

Starting Avahi daemon... Daemon already running on PID 2504
                                                           [FAILED]


Comment 7 Tim Waugh 2006-01-05 11:37:14 UTC
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 17:44:33 UTC
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 17:45:20 UTC
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 17:47:42 UTC
The avahi message certainly needs a separate bug report, yes, against avahi.

Comment 11 Reuben Farrelly 2006-01-06 22:15:29 UTC
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 12:40:01 UTC
Yes, that's fine I think.