Bug 693202 - chkconfig S## prioritory set inconsistently for initscript with Requires-Start: $network
Summary: chkconfig S## prioritory set inconsistently for initscript with Requires-Star...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: chkconfig
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-03 14:10 UTC by Hans de Goede
Modified: 2014-03-17 03:27 UTC (History)
2 users (show)

Fixed In Version: chkconfig-1.3.57-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 771455 (view as bug list)
Environment:
Last Closed: 2011-05-03 04:54:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch (549 bytes, patch)
2011-04-05 16:36 UTC, Bill Nottingham
no flags Details | Diff

Description Hans de Goede 2011-04-03 14:10:18 UTC
Description of problem:
The tgtd (iscsi target daemon) initscript specifies a S## priority of 11 in its chkconfig headers, and "Requires-Start: $network" in its LSB header.

When initially enabled through: "systemctl enable tgtd.service", which
redirects the call to chkconfig, the tgtd services gets assigned a S## priority of its requested S11. Which on my system is correct, since the good old network service is enabled which provides $network, and the NetworkManager service is disabled.

But when I then enable another service, say iscsid, it gets moved to S24 for some
magical reason.

Since the iscsid service does not have any Requires which influence the tgtd service enabling it should not move the tgtd service to S24 (which is directly after the requestes S## prioritoy from the chkconfig header of the disabled NetworkManager).

Comment 1 Hans de Goede 2011-04-03 14:12:00 UTC
p.s.

I realize that having a "Requires-Start: $network" is not a good idea in general in a NetworkManager world, but that is a different discussion then the weird moving of the S## priority of tgtd without any valid reason.

Comment 2 Bill Nottingham 2011-04-04 20:50:39 UTC
At what point did you enable tgtd.service, and in what environment?

Comment 3 Hans de Goede 2011-04-05 07:24:00 UTC
Hi,

(In reply to comment #2)
> At what point did you enable tgtd.service, and in what environment?

I enabled and disabled it several times, all from a xterm under gnome-shell, so from a fully booted & logged in system. All invocations where done as:
sudo systemctl enable foo
resp:
sudo systemctl disable foo

When ever I enable tgtd it gets a S## priority of 11, as soon as I also enable either iscsid or iscsi (haven't tried with others) it gets moved to 24.

Regards,

Hans

Comment 4 Bill Nottingham 2011-04-05 16:13:59 UTC
Is NM installed at all, and if so, is it disabled in all runlevels?

Comment 5 Bill Nottingham 2011-04-05 16:24:59 UTC
I'm unable to reproduce your issue with NM disabled. I *am* able to reproduce it with NM enabled; it's only moved the second time it's operated on.

Comment 6 Bill Nottingham 2011-04-05 16:36:28 UTC
Created attachment 490032 [details]
patch

The attached should fix the issue of it moving on subsequent chkconfig invocations.

The problem is that the dependency frobber for a specific service checks to make sure that the service is similarly configured to whatever is providing its dependencies. However, if you're enabling a disabled service, or disabling an enabled service, the states won't match initially.

This fixes it by setting the state on the filesystem before calling the dependency frobber. It's a bit of a hack, in that it means when doing enable/disable, you'll get the state set twice.

Comment 7 Hans de Goede 2011-04-27 10:32:10 UTC
I've given the attached patch a try, and it indeed fixes the issue of the moving, tgtd now starts at position 24 and stays there.

With this patch I'm seeing other ordering issues with the iscsi service though, 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...

Comment 8 Bill Nottingham 2011-04-27 17:10:33 UTC
Will have to test that. Patch merged, will be in a future build.

Comment 9 Fedora Update System 2011-04-27 17:49:04 UTC
chkconfig-1.3.52-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/chkconfig-1.3.52-1.fc15

Comment 10 Fedora Update System 2011-04-28 19:01:50 UTC
Package chkconfig-1.3.52-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing chkconfig-1.3.52-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/chkconfig-1.3.52-1.fc15
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2011-05-03 04:53:54 UTC
chkconfig-1.3.52-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Hans de Goede 2011-05-03 09:04:37 UTC
I'm going to open a new bug for the issue described in comment #7 to make sure that that does not fall through the cracks.

Comment 13 Fedora Update System 2012-01-04 20:27:18 UTC
chkconfig-1.3.57-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/chkconfig-1.3.57-1.fc16

Comment 14 Fedora Update System 2012-01-15 20:06:02 UTC
chkconfig-1.3.57-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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