Bug#501580: open-iscsi: don't stoptargets on stop
Ferenc Wagner
Version: 2.0.870~rc3-0.1
Severity: important
Tags: patch
Hi,
When open-iscsi stop is executed on system shutdown, it invokes the
stoptargets shell function, which logs out of all targets. This breaks
systems where root is on iSCSI. I decided to leave the job of killing
iscsid to sendsigs later in the boot process by
--- open-iscsi.orig 2008-10-08 14:47:16.562492743 +0200
+++ open-iscsi 2008-10-08 17:36:47.877662527 +0200
@@ -125,6 +125,10 @@
}
stop() {
+ if [ -f /etc/iscsi/iscsi.initramfs ]; then
+ log_warning_msg "/etc/iscsi/iscsi.initramfs present, not stopping iscsid yet"
+ return 0
+ fi
stoptargets
log_daemon_msg "Stopping iSCSI initiator service"
start-stop-daemon --stop --quiet --pidfile $PIDFILE --signal KILL --exec $DAEMON
as that buys me a little more safety, but probably excluding stoptargets
would be enough.
Actually, I'm tempted to say that open-iscsi stop should NEVER execute
stoptargets. That would also help upgrades (which currently break all
live iSCSI mounts).
Btw. why the above --signal KILL? The default SIGTERM seemed to be
enough for me, just as iscsiadm --killiscsid=0.
Thanks,
Feri.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-xen-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages open-iscsi depends on:
ii libc6 2.7-13 GNU C Library: Shared libraries
open-iscsi recommends no packages.
open-iscsi suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ritesh Raj Sarraf
We are currently triaging bugs for open-iscsi.
First of all, thank you for the patch. The patch looks good.
But we might need something more than this for data LUNs that are on other
mount points.
But that will not help trigger a real restart where say, you discovered more
targets and removed the old ones, if you don't do a stoptargets, you won't be
able to logout of those targets.
Comments ??
Regards,
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
Ferenc Wagner
> We are currently triaging bugs for open-iscsi.
Hi Ritesh,
Thank you very much for investing work into open-iscsi! It's much
needed and also much appreciated.
> First of all, thank you for the patch. The patch looks good.
> But we might need something more than this for data LUNs that are on other
> mount points.
Well, I've been using this on my iSCSI-rooted machines, but I don't
consider it a perfect/full/good solution to the general problem.
>> When open-iscsi stop is executed on system shutdown, it invokes the
>> stoptargets shell function, which logs out of all targets. This breaks
>> systems where root is on iSCSI. I decided to leave the job of killing
>> iscsid to sendsigs later in the boot process by
>>
>> --- open-iscsi.orig 2008-10-08 14:47:16.562492743 +0200
>> +++ open-iscsi 2008-10-08 17:36:47.877662527 +0200
>> @@ -125,6 +125,10 @@
>> }
>>
>> stop() {
>> + if [ -f /etc/iscsi/iscsi.initramfs ]; then
>> + log_warning_msg "/etc/iscsi/iscsi.initramfs present, not stopping iscsid yet"
>> + return 0
>> + fi
>> stoptargets
>> log_daemon_msg "Stopping iSCSI initiator service"
>> start-stop-daemon --stop --quiet --pidfile $PIDFILE --signal KILL --exec $DAEMON
>>
>> as that buys me a little more safety, but probably excluding stoptargets
>> would be enough.
>>
>> Actually, I'm tempted to say that open-iscsi stop should NEVER execute
>> stoptargets. That would also help upgrades (which currently break all
>> live iSCSI mounts).
>
> But that will not help trigger a real restart where say, you discovered more
> targets and removed the old ones, if you don't do a stoptargets, you won't be
> able to logout of those targets.
I think it's the other way around: if you DO stoptargets, then you won't
be able to log out of the targets. But that probably doesn't matter much.
In my opinion, the open-iscsi init scripts and general behaviour should
be more modelled after that of multipath-tools(-boot), even "around"
that, as iscsi devices can be multipathed (multipath maintainer Cc-d).
/usr/share/initramfs-tools/scripts/local-top/multipath already requires
iscsi, so the scene is set. :) Basically start iscsi before multipath,
and stop it after multipath. Btw. "starting" multipath in the initramfs
doesn't entail starting multipathd, which is similar in purpose to
iscsid. Similarly, stopping multipath means stopping multipathd, not
flushing the in-kernel mappings of the devices. iSCSI should behave
much the same, although it's complicated by the login/logout issue,
which could be optionally supported by the open-iscsi init script via
separate verbs for the convenience of the sysadmin. Or it could be left
out and relegated to iscsiadm for the sake of simplicity.
In short: I'd still say that /etc/init.d/open-iscsi stop should not
execute stoptargets. It could still support the stoptargets verb, but
it would be nice to stop unused targets only. However, I don't know how
one could do that.
--
Regards,
Feri.
Ritesh Raj Sarraf
> > But that will not help trigger a real restart where say, you discovered
> > more targets and removed the old ones, if you don't do a stoptargets,
> > you won't be able to logout of those targets.
>
> I think it's the other way around: if you DO stoptargets, then you won't
> be able to log out of the targets. But that probably doesn't matter much.
>
> In my opinion, the open-iscsi init scripts and general behaviour should
> be more modelled after that of multipath-tools(-boot), even "around"
> that, as iscsi devices can be multipathed (multipath maintainer Cc-d).
> /usr/share/initramfs-tools/scripts/local-top/multipath already requires
> iscsi, so the scene is set. :) Basically start iscsi before multipath,
> and stop it after multipath. Btw. "starting" multipath in the initramfs
> doesn't entail starting multipathd, which is similar in purpose to
> iscsid. Similarly, stopping multipath means stopping multipathd, not
> flushing the in-kernel mappings of the devices. iSCSI should behave
> much the same, although it's complicated by the login/logout issue,
> which could be optionally supported by the open-iscsi init script via
> separate verbs for the convenience of the sysadmin. Or it could be left
> out and relegated to iscsiadm for the sake of simplicity.
>
> In short: I'd still say that /etc/init.d/open-iscsi stop should not
> execute stoptargets. It could still support the stoptargets verb, but
> it would be nice to stop unused targets only. However, I don't know how
> one could do that.
>
I totally agree. stoptargets (logout of iscsi sessions) is not really
required. And if we *really* need to have that, we first need to ensure that
all iscsi devices are unmounted. SLES does something similar (but still
buggy).
I will check is open-iscsi has the equivalent of `multipath -F`
On similar topic, I want to bring the following bug to your attention. This
involves both iscsi and multipath.
https://bugzilla.redhat.com/show_bug.cgi?id=456228
Ferenc Wagner
> I will check is open-iscsi has the equivalent of `multipath -F`
Yes, device-mapper devices make their open count easily accessible.
However, I know of no similar facility in (i)SCSI or in the block layer.
> On similar topic, I want to bring the following bug to your attention. This
> involves both iscsi and multipath.
> https://bugzilla.redhat.com/show_bug.cgi?id=456228
Interesting. I personally don't use multipath over iSCSI, but still, I
feel like the solution in that bug report is only a workaround for two
separate bugs: 1) multipath shouldn't fast fail its last path and 2)
iscsid shouldn't fail running I/O when starting up. Maybe there're good
reasons for these implementation choices, though. But I wonder...
--
Thanks,