Bug 497926 - chkconfig could use some LSB compliance work
chkconfig could use some LSB compliance work
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: chkconfig (Show other bugs)
12
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-27 17:27 EDT by Jack Perdue
Modified: 2014-03-16 23:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:55:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jack Perdue 2009-04-27 17:27:49 EDT
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.
Comment 1 Nate Straz 2009-11-06 11:15:47 EST
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
Comment 2 Nate Straz 2009-11-06 11:17:15 EST
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
Comment 3 Nate Straz 2009-11-06 11:21:37 EST
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
Comment 4 Bill Nottingham 2009-11-06 12:41:39 EST
This can be fixed by running 'resetpriorities' after turning the service on. (That's a workaround, obvs.)
Comment 5 Bug Zapper 2009-11-18 07:51:06 EST
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
Comment 6 Bug Zapper 2010-11-04 07:18:36 EDT
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
Comment 7 Bug Zapper 2010-12-05 01:55:44 EST
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.

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