+++ This bug was initially created as a clone of Bug #693202 +++

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).

--- Additional comment from hdegoede on 2011-04-03 10:12:00 EDT ---

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.

--- Additional comment from notting on 2011-04-04 16:50:39 EDT ---

At what point did you enable tgtd.service, and in what environment?

--- Additional comment from hdegoede on 2011-04-05 03:24:00 EDT ---

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

--- Additional comment from notting on 2011-04-05 12:13:59 EDT ---

Is NM installed at all, and if so, is it disabled in all runlevels?

--- Additional comment from notting on 2011-04-05 12:24:59 EDT ---

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.

--- Additional comment from notting on 2011-04-05 12:36:28 EDT ---

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.

--- Additional comment from hdegoede on 2011-04-27 06:32:10 EDT ---

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...

--- Additional comment from notting on 2011-04-27 13:10:33 EDT ---

Will have to test that. Patch merged, will be in a future build.

--- Additional comment from updates on 2011-04-27 13:49:04 EDT ---

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

--- Additional comment from updates on 2011-04-28 15:01:50 EDT ---

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).

--- Additional comment from updates on 2011-05-03 00:53:54 EDT ---

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.

--- Additional comment from hdegoede on 2011-05-03 05:04:37 EDT ---

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.