[Pkg-iscsi-maintainers] Bug#809334: Bug#809320: open-iscsi: no session termination on stop
Ritesh Raj Sarraf
rrs at debian.org
Wed Dec 30 09:56:02 UTC 2015
Hello Christian,
On Tue, 2015-12-29 at 18:43 +0100, Christian Seiler wrote:
> I have been trying to play around with my VM setup, to build an
> > iSCSI
> > SAN Boot Setup. In doing that, I noticed something odd. Perhaps you
> > may
> > have some pointers.
> >
> > root at debian-sanboot:~# /etc/init.d/open-iscsi stop
> > [ ok ] Stopping open-iscsi (via systemctl): open-iscsi.service.
>
> So this calls systemctl stop open-iscsi - but that is always
> successful
> if systemd thinks the service didn't start up, so it assumes it
> doesn't
> have to stop anything. You did report this, so I'm merging both bug
> reports.
>
That's interesting behavior. But something which can be tackled later.
There could be services that activate in initrd. Either systemd needs
to start in initrd, or else, there needs to be a tracking mechanism.
At this time, neither multipathd nor iscsid, is propagated to initrd.
But IIRC, other distributions are doing that already. I haven't really
felt the need to push these daemons, so for the near future, nothing
should change for us.
> As for the root cause:
>
> On 12/29/2015 01:48 PM, Ritesh Raj Sarraf wrote:
> > root at debian-sanboot:~# systemctl status -l open-iscsi
> > ● open-iscsi.service - Login to default iSCSI targets
> > Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled;
> > vendor preset: enabled)
> > Active: failed (Result: exit-code) since Tue 2015-12-29 17:52:34
> > IST; 17min ago
> > Docs: man:iscsiadm(8)
> > man:iscsid(8)
> > Process: 558 ExecStart=/sbin/iscsiadm -m node --
> > loginall=automatic (code=exited, status=15)
> > Process: 554 ExecStartPre=/bin/systemctl --quiet is-active
> > iscsid.service (code=exited, status=0/SUCCESS)
> > Main PID: 558 (code=exited, status=15)
> >
> > Dec 29 17:52:35 debian-sanboot iscsiadm[558]: iscsiadm: Could not
> > log into all portals
>
> So what's going on is that iscsiadm -m node --loginall=automatic
> exits
> with exit code 15, which makes systemd think that the login to the
> iSCSI sessions didn't succeed. This is problematic in two ways:
>
> - the second ExecStart= line in the native service will not be
> called,
> so the compatibility-style auto-activation of LVM LVs won't work
> as
> expected (if you use lvmetad or don't use LVM you don't need it,
> so
> in that case it doesn't matter - and mounting is done by systemd
> itself anyway, so in modern setups the second ExecStart= script is
> completely unnecessary)
Oh! Yes. I didn't use LVM. Perhaps the next test setup, I'll build that
too.
>
> - systemd will think the service is stopped, which is the root
> problem of your other bug that session logout doesn't occur
>
> According to the manpage, iscsiadm returns code 15 when a session is
> already logged in, so my guess is that you have a setup where one of
> the portals is activated in initramfs at boot - but is still
> configured to be logged into at boot.
>
Yes. That is correct. So, one option would be to set that portal's
login to manual.
> So one solution could be to use SuccessExitStatus=0 15 in the unit to
> say that 'already logged in' is not an error condition (and possibly
> others, I'd have to check the manpage) - but I think that is
> short-sighted, as this will prevent systemd from thinking the service
> is active and thus not terminate any active sessions (including
> manually activated ones) on shutdown.
>
> Therefore, I think the correct solution is to simply ignore errors
> from the iscsiadm call in the open-iscsi.service file,
>
You mean ignore errors of all types ?
What if one of the session couldn't be established because the target's
respective interface had a failure ?
> ExecStart=-/sbin/iscsiadm -m node --loginall=automatic
> (note the "=-" instead of "=")
>
> in order to make sure that systemd thinks the service is always
> active. This will only log errors to syslog/journal when they occur
> if iSCSI login fails - but not set the status of the service to
> failed - but it will make sure that shutdown works properly in all
> cases - and if there really is an error with iSCSI login, usually
> there will be followup errors anyway, because block devices don't
> appear, so the user will have feedback in any case.
>
Yes. This answers my above question too. I think there still may be
some corner cases, and I'll keep digging. I'll do more tests of
interface up/down, and see this above mentioned condition, on how it'd
behave.
> I would therefore suggest you try adding the minus sign to the
> ExecStart= line as described above - and unless you find any other
> issues, just upload -13 with that change to unstable.
>
This definitely improved the reporting.
root at debian-sanboot:~# systemctl status open-iscsi
● open-iscsi.service - Login to default iSCSI targets
Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled;
vendor preset: enabled)
Active: active (exited) since Wed 2015-12-30 15:00:23 IST; 7min ago
Docs: man:iscsiadm(8)
man:iscsid(8)
Process: 599 ExecStart=/lib/open-iscsi/activate-storage.sh
(code=exited, status=0/SUCCESS)
Process: 568 ExecStart=/sbin/iscsiadm -m node --loginall=automatic
(code=exited, status=15)
Process: 561 ExecStartPre=/bin/systemctl --quiet is-active
iscsid.service (code=exited, status=0/SUCCESS)
Main PID: 599 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/open-iscsi.service
Dec 30 15:00:20 debian-sanboot systemd[1]: Starting Login to default
iSCSI targets...
Dec 30 15:00:20 debian-sanboot iscsiadm[568]: iscsiadm: default: 1
session requested, but 1 already present.
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: iscsiadm: Could not log
into all portals
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Logging in to [iface:
default, target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.41,3260] (multiple)
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Logging in to [iface:
default, target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.42,3260] (multiple)
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Logging in to [iface:
default, target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.43,3260] (multiple)
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Login to [iface: default,
target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.41,3260] successful.
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Login to [iface: default,
target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.42,3260] successful.
Dec 30 15:00:21 debian-sanboot iscsiadm[568]: Login to [iface: default,
target: iqn.2003-01.org.linux-iscsi.debian.sanboot, portal:
172.16.20.43,3260] successful.
Dec 30 15:00:23 debian-sanboot systemd[1]: Started Login to default
iSCSI targets.
root at debian-sanboot:~#
> (Sorry, during the next 3 weeks I won't have time to test this
> myself.)
>
No problem. I think none of this is critical warranting an immediate
upload. I'll keep playing, and report my findings on this bug report.
Later we can work on a new upload.
> --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-iscsi-maintainers/attachments/20151230/9fbcd02b/attachment-0003.sig>
More information about the Pkg-iscsi-maintainers
mailing list