Bug 170367 - chkconfig-1.3.13.2-1 bug when use LSB compliant "Required-Start:"
Summary: chkconfig-1.3.13.2-1 bug when use LSB compliant "Required-Start:"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: chkconfig
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 168424
TreeView+ depends on / blocked
 
Reported: 2005-10-11 00:46 UTC by Jay Turner
Modified: 2015-01-08 00:10 UTC (History)
6 users (show)

Fixed In Version: RHBA-2006-0017
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-15 15:44:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0017 0 qe-ready SHIPPED_LIVE Updated chkconfig package available 2006-03-14 05:00:00 UTC

Description Jay Turner 2005-10-11 00:46:01 UTC
+++ This bug was initially created as a clone of Bug #168457 +++

Description of problem:
when using LSB compliant "Required-Start:" , chkconfig does not create the 
appropriate Snnfoo scripts.
This can result in Start and Stop scripts not being run in the sequential order 
that the developer intended these scripts to be run.
Additionally, chkconfig creates S-1foo named scripts, which are not removed 
when one executes # chkconfig --del foo

Version-Release number of selected component (if applicable):
chkconfig-1.3.13.2-1

How reproducible:
Always
cat /etc/init.d/foo 
#!/bin/sh #
# chkconfig:      345 40 60
# description:    foo script
# Required-Start: $network

Steps to Reproduce 1 bug:
# chkconfig --list foo service foo supports chkconfig, but is not referenced in 
any runlevel (run 'chkconfig --add foo')
# chkconfig --add foo
# find . -name "*foo*"
./rc6.d/K60foo
./init.d/foo
./rc2.d/K60foo
./rc4.d/S-1foo    <=== huh?
./rc1.d/K60foo
./rc0.d/K60foo
./rc5.d/S-1foo    <=== huh?
./rc3.d/S-1foo    <=== huh?

Actual results:
./rc4.d/S-1foo    <=== huh?
./rc5.d/S-1foo    <=== huh?
./rc3.d/S-1foo    <=== huh?

Expected results:
./rc4.d/S40foo    
./rc5.d/S40foo   
./rc3.d/S40foo    

Steps to reproduce 2 bug
# chkconfig --del foo

Actual results
# find . -name "*foo*"
./init.d/foo
./rc4.d/S-1foo
./rc5.d/S-1foo
./rc3.d/S-1foo

-- Additional comment from notting on 2005-09-16 12:16 EST --


*** This bug has been marked as a duplicate of 161870 ***

-- Additional comment from notting on 2005-10-07 16:13 EST --
Reopening, this is not a duplicate of 161870.

-- Additional comment from notting on 2005-10-07 16:15 EST --
*** Bug 163389 has been marked as a duplicate of this bug. ***

Comment 3 gajanovic_dan 2005-11-10 02:40:55 UTC
Looking at chkconfig.c v1.3.13.2, line 171, we have:

    if (s.isLSB && (s.sPriority <= -1) && (s.kPriority <= -1))
        frobDependencies(&s);

Consider initd scripts foo and bar:

# foo
# chkconfig: 35 95 10
### BEGIN INIT INFO
# Required-Start: network
### END INIT INFO

and

# bar
# chkconfig: 35 95 10
### BEGIN INIT INFO
# Required-Stop: network
### END INIT INFO

In both cases, only one of Required-Start/Required-Stop is provided
(which is valid according to the LSB spec going back as far as 1.0).
However, after readServiceInfo(), we will have
(s.isLSB, s.sPriority, s.kPriority) set to
(1, -1, 10) and (1, 95, -1), respectively. In both cases, addService()
concludes that the script is not LSB-compliant, and proceeds to use
-1 verbatim. The result will be S-1foo and K-1bar. 

If chkconfig decides that it will ignore the LSB-style directives, then
it should at least not let them corrupt the information provided by
'# chkconfig:' and vice versa.

In prior versions of chkconfig, foo and bar used to be installed properly
using the info provided by '# chkconfig:'. 1.3.13.2 breaks these scripts.

Comment 4 Bill Nottingham 2005-11-10 23:31:39 UTC
Built in 1.3.13.3.

Comment 11 Red Hat Bugzilla 2006-03-15 15:44:25 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0017.html



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