Bug 681275 - /etc/rc.d/init.d/iscsi is broken
Summary: /etc/rc.d/init.d/iscsi is broken
Keywords:
Status: CLOSED DUPLICATE of bug 692230
Alias: None
Product: Fedora
Classification: Fedora
Component: iscsi-initiator-utils
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mike Christie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-01 15:56 UTC by David Zeuthen
Modified: 2013-03-06 04:06 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-04-26 07:43:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Zeuthen 2011-03-01 15:56:55 UTC
See [1] for details. Additionally, the iscsi-initiator-utils package does not ship any special systemd sauce.

For now, I use

 iscsiadm --mode node --loginall=automatic

resp.

 iscsiadm --mode node --logoutall=automatic

instead of 'service iscsi start' and 'service iscsi stop'.

[1]

<davidz> mezcalero: hmm, systemd breaks '/etc/init.d/iscsi stop' (and start) - is this a known problem?

<mezcalero> davidz: no clue, what excactly doesn't work?
 davidz: i have no iscsi to test...
<mezcalero> and i have not seen a report about this yet

<davidz> mezcalero: look at /etc/init.d/iscsi
 mezcalero: in particular /etc/NetworkManager/dispatcher.d/04-iscsi calls /etc/init.d/iscsi
 this tears down / brings up the iscsi connections when NM says the network connection is acquired / lost
 mezcalero: here are some notes on setting up iscsi so you can test: http://cgit.freedesktop.org/udisks/tree/doc/TODO-ISCSI
 either way, I'm confused why running /etc/init.d/iscsi is redirecting to systemctl
 e.g. I run
 # /etc/init.d/iscsi start
 Starting iscsi (via systemctl):                            [  OK  ]
 and nothing happens...
 there is no unit called iscsi
 (there's one called iscsid.service but that's different)
<davidz> either way, all this worked before systemd so I cannot see how it's not a systemd bug...

Comment 1 David Zeuthen 2011-03-01 16:15:57 UTC
Actually this is not a systemd bug. The problem is that /etc/rc.d/init.d/iscsi checks for /var/lock/subsys/NetworkManager but on f15 this no longer exists... Reassigning to iscsi-initiator-utils...

Comment 2 Hans de Goede 2011-03-02 08:17:28 UTC
(In reply to comment #1)
> Actually this is not a systemd bug. The problem is that /etc/rc.d/init.d/iscsi
> checks for /var/lock/subsys/NetworkManager but on f15 this no longer exists...
> Reassigning to iscsi-initiator-utils...

I'll try to make some time to look into this. So what would be the way now to check
if we have a configured network connection ?

Comment 3 Lennart Poettering 2011-03-02 13:42:54 UTC
(In reply to comment #2)

> I'll try to make some time to look into this. So what would be the way now to
> check
> if we have a configured network connection ?

Well, what you did is check whether NM was running, not whether there was a network connection up.

The right way to check whether a network connection is available is writing software that follows netlink and handles configuration changes properly.

Networks are dynamic these day. They come and go, relying on static configuration and a point in time is wrong these days.

That said, nmcli is probably what you want to be using.

Comment 4 David Zeuthen 2011-03-02 15:10:09 UTC
(In reply to comment #3)
> (In reply to comment #2)
> 
> > I'll try to make some time to look into this. So what would be the way now to
> > check
> > if we have a configured network connection ?
> 
> Well, what you did is check whether NM was running, not whether there was a
> network connection up.
> 
> The right way to check whether a network connection is available is writing
> software that follows netlink and handles configuration changes properly.
> 
> Networks are dynamic these day. They come and go, relying on static
> configuration and a point in time is wrong these days.
> 
> That said, nmcli is probably what you want to be using.

Well, what iscsi-initiator-utils was doing was already correct since it installed a /etc/NetworkManager/dispatcher.d hook to start/stop this service when the networking state changed (start when up, stop when down. And you can't really blame this package for /var/lock/subsys/NetworkManager disappearing...

So I think the fix just requires changing the check for /var/lock/subsys/NetworkManager to something else.. maybe systemctl(1)? I don't know...

Comment 5 Hans de Goede 2011-04-26 07:43:10 UTC
In the mean time this issue was reported again, and fixed under bug 692230, marking this one as a dup...

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


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