Ritesh Raj Sarraf <r...@researchut.com> writes:
> 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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
