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: | hplip | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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. 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 :) 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........ 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. 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..... 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] This might be fixed by the patch in bug #176966. Does hplip-0.9.7-7 still do this? 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... Oh, I still get the Avahi message though... Is that normal? Should I file a separate bug report for that? The avahi message certainly needs a separate bug report, yes, against avahi. 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? Yes, that's fine I think. |