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@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@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@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@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
signature.asc
Description: This is a digitally signed message part
