Description of problem: Both these issues have to do with chkconfig.c's frobDependencies(). 1) the LSB frobber queries init.d when doing dependency resolution, regardless of whether the service has actually been enabled in run level 1-6. As mentioned below, this is probably a dupe bug report 2) the LSB frobber doesn't resolve in the order that dependencies may have run or whether a dependency has already been satisfied (and therefore isn't dependent upon a later definition if there are two or more satisfications of the dependency). I don't believe this has been addressed in previous bug reports. I ran into the is problem on Fedora 10 where I (unneededly) had both ypbind and NetworkManager installed. Because ypbind wants $network and because NetworkManager defaults to the same start priority as ypbind, ypbind was getting bumped from 27 to 28 which then broke autofs, etc. Even if I did a "chkconfig --del" or "chkconfig off" on NetworkManager (which I had). I mentioned this in another bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=489200#c6 Version-Release number of selected component (if applicable): chkconfig-1.3.38-1.i386 How reproducible: I believe both problems are always reproducible. Steps to Reproduce: Simply install NetworkManager and ybind, disable NetworkManager (with chkconfig -del or off) and then disable/enable ypbind. Actual results: ypbind gets it start priority needlessly bumped. Expected results: chkconfig realizes that: a) NetworkManager isn't even being started and so shouldn't have an impact on the start priority b) that the $network dependency was already resolved by the (activated/enabled) initscripts "network" (rc3.d/S10network) script and therefore doesn't need to wait for NetworkManager (and therefore retains its 27 start priority). Additional info: Note, I realize that problem #1 is very similar to, if not a duplicate of bug 487979. Given the change sparking Bill N.s #10 comment there, that would seem to resolve the lack of LSB compliance (LSB 3.1 Chapter 20 Section 3 under "Provides" indicates that the dependency is only provided if the script is run with "start" first [i.e. if it isn't run, then it doesn't provide anything], so simply relying upon its existence in init.d without checking rc3-5.d is incorrect). The issue is also addressed in bug 474223. However, I don't see anything that addresses problem #2. Given the use of readdir() in frobDependencies(), which isn't in any particular order (and certainly not in sorted/numerical order), and that it continues to read scripts and considering their Provides: regardless of whether any other numerically previous script already satisfied the needed Required-Start dependency, then the priority is needlessly upped. From how I read the LSB, the first "Provides" is sufficient to satisfy the "Required-Start" and therefore the second second "Provides" should have no impact. Obviously, most people won't being using NetworkManager in an ypbind/NIS environment. But it does serve as an example of how chkconfig could do a smarter/saner job of altering priorities.
We're hitting a related issue with recent rawhide trees and cman clustering bits. NetworkManager is on my default and network is off. cman gets placed before NetworkManager even though it depends on $network and only NetworkManager provides it. [root@dct-xen-09 rc3.d]# pwd /etc/rc.d/rc3.d [root@dct-xen-09 rc3.d]# ls S* S06cpuspeed S12rsyslog S24avahi-daemon S26udev-post S90crond S08ip6tables S13irqbalance S25netfs S27NetworkManager S95atd S08iptables S15mdmonitor S26acpid S55sshd S99local S11auditd S22messagebus S26haldaemon S56xinetd [root@dct-xen-09 rc3.d]# chkconfig cman on [root@dct-xen-09 rc3.d]# ls S* S06cpuspeed S12rsyslog S22messagebus S26haldaemon S56xinetd S08ip6tables S13irqbalance S24avahi-daemon S26udev-post S90crond S08iptables S15mdmonitor S25netfs S27NetworkManager S95atd S11auditd S21cman S26acpid S55sshd S99local ## cman gets added at 21, before NetworkManager If I chkconfig cman on a second time, it moves to the right location. [root@dct-xen-09 rc3.d]# chkconfig cman off [root@dct-xen-09 rc3.d]# ls S* S06cpuspeed S12rsyslog S24avahi-daemon S26udev-post S90crond S08ip6tables S13irqbalance S25netfs S27NetworkManager S95atd S08iptables S15mdmonitor S26acpid S55sshd S99local S11auditd S22messagebus S26haldaemon S56xinetd [root@dct-xen-09 rc3.d]# chkconfig cman on [root@dct-xen-09 rc3.d]# ls S* S06cpuspeed S12rsyslog S22messagebus S26haldaemon S56xinetd S08ip6tables S13irqbalance S24avahi-daemon S26udev-post S90crond S08iptables S15mdmonitor S25netfs S27NetworkManager S95atd S11auditd S21cman S26acpid S55sshd S99local [root@dct-xen-09 rc3.d]# chkconfig cman on [root@dct-xen-09 rc3.d]# ls S* S06cpuspeed S12rsyslog S24avahi-daemon S26udev-post S56xinetd S08ip6tables S13irqbalance S25netfs S27NetworkManager S90crond S08iptables S15mdmonitor S26acpid S28cman S95atd S11auditd S22messagebus S26haldaemon S55sshd S99local
Packages installed for comment #1 chkconfig-1.3.42-2.1.x86_64 cman-3.0.0-21.el6.x86_64 NetworkManager-0.7.996-1.git20090826.el6.x86_64
Reproduced on rawhide with the following package versions: chkconfig-1.3.44-1.i686 cman-3.0.4-1.fc12.i686 NetworkManager-0.7.996-5.git20091021.fc12.i686 [root@morph-01 rc3.d]# ls S* S00microcode_ctl S24avahi-daemon S28rpcsvcgssd S02lvm2-monitor S24clvmd S55sshd S06cpuspeed S25netfs S56xinetd S08ip6tables S26acpid S60nfs S08iptables S26haldaemon S80sendmail S11auditd S26pcscd S90crond S12rsyslog S26udev-post S95atd S13irqbalance S27NetworkManager S98tog-pegasus S13rpcbind S28nfslock S99local S15mdmonitor S28rpcgssd S22messagebus S28rpcidmapd [root@morph-01 rc3.d]# chkconfig cman on [root@morph-01 rc3.d]# ls S* S00microcode_ctl S22messagebus S28rpcidmapd S02lvm2-monitor S24avahi-daemon S28rpcsvcgssd S06cpuspeed S24clvmd S55sshd S08ip6tables S25netfs S56xinetd S08iptables S26acpid S60nfs S11auditd S26haldaemon S80sendmail S12rsyslog S26pcscd S90crond S13irqbalance S26udev-post S95atd S13rpcbind S27NetworkManager S98tog-pegasus S15mdmonitor S28nfslock S99local S21cman S28rpcgssd [root@morph-01 rc3.d]# chkconfig cman on [root@morph-01 rc3.d]# ls S* S00microcode_ctl S24avahi-daemon S28rpcidmapd S02lvm2-monitor S24clvmd S28rpcsvcgssd S06cpuspeed S25netfs S55sshd S08ip6tables S26acpid S56xinetd S08iptables S26haldaemon S60nfs S11auditd S26pcscd S80sendmail S12rsyslog S26udev-post S90crond S13irqbalance S27NetworkManager S95atd S13rpcbind S28cman S98tog-pegasus S15mdmonitor S28nfslock S99local S22messagebus S28rpcgssd
This can be fixed by running 'resetpriorities' after turning the service on. (That's a workaround, obvs.)
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.