Bug 771741 - sysv service start prio not adjusted when a Should-Start dep gets enabled
Summary: sysv service start prio not adjusted when a Should-Start dep gets enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: chkconfig
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Bill Nottingham
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On: 701573
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-04 19:43 UTC by Bill Nottingham
Modified: 2014-03-17 03:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When an LSB initscript was enabled, scripts with dependencies on the script being enabled would not always be set up correctly, due to a bug in how LSB dependencies are handled. chkconfig has been changed to properly calculate script dependencies on scripts being installed, and now enabling of LSB services works correctly.
Clone Of: 701573
Environment:
Last Closed: 2012-06-20 14:04:13 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0873 0 normal SHIPPED_LIVE chkconfig bug fix update 2012-06-19 20:47:48 UTC

Description Bill Nottingham 2012-01-04 19:43:53 UTC
+++ This bug was initially created as a clone of Bug #701573 +++

Recently the iscsi sysv init script has grown the following deps:
Should-Start:      tgtd
Should-Stop:       tgtd

So that logging in to locally hosted iscsi targets works properly, this means
it should be ordered after tgtd, but if I disable iscsi + tgtd then:
1) enable iscsi, gets position 13
2) enable tgtd gets pos 24, iscsi stays at position 13

Then enabling / disabling some other service (tried iscsid) moves iscsi to 25,
but this should have happened as soon as tgtd was enabled...

--- Additional comment from notting on 2012-01-04 13:29:03 EST ---

The problem isn't necessarily 'Should-Start' dependencies.

The algorithm currently is:

a) resolve all existing scripts
b) resolve our target script

So, if something in set A has a dep on what's being enabled in B, and B gets moved, there's no step to cover for that.

(This is what happens when the algorithm isn't a real dependency solver.)

--- Additional comment from notting on 2012-01-04 14:23:24 EST ---

This is fixed in http://git.fedorahosted.org/git/?p=chkconfig.git;a=commitdiff;h=679231f31c775326e2c5e78c1821149ded1dbb60, although you don't want to be cherry-picking that... grab the whole series of recent changes.

Comment 2 Bill Nottingham 2012-02-24 19:37:56 UTC
Built as 1.3.49.3-1.

Comment 4 Bill Nottingham 2012-03-14 19:40:53 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When an LSB initscript was enabled, scripts with dependencies on the script being enabled would not always be set up correctly, due to a bug in how LSB dependencies are handled. chkconfig has been changed to properly calculate script dependencies on scripts being installed, and now enabling of LSB services works correctly.

Comment 6 Martin Cermak 2012-04-16 15:17:06 UTC
Comment#5 => Verified.

Comment 8 errata-xmlrpc 2012-06-20 14:04:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0873.html


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