## SUMMARY 1 Affects open-iscsi (NOT systemd):
* ISCSID NEEDS TO BE UP & RUNNING (AND LOGGED TO PORTAL) FOR THE LOGOUT TO WORK https://pastebin.canonical.com/197359/ Daemon shutdown documentation in iscsiadm command says (about stopping iscsid daemon with iscsiadm -k): """ ... This will immediately stop all iscsid operations and shutdown iscsid. It does not logout any sessions. Running this command is the same as doing "killall iscsid". Neither should normally be used, because if iscsid is doing error recovery or if there is an error while iscsid is not running, the system may not be able to recover. This command and iscsid's SIGTERM handling are experimental. """ Basically meaning you're not able to shutdown the daemon in a clean manner if you have connected sessions. And basically, checking the pastebin, you see the need for running iscsid daemon to logout through iscsiadm command. So from: (systemctl edit --full open-iscsi.service) ... Wants=network-online.target remote-fs-pre.target iscsid.service After=network-online.target iscsid.service Before=remote-fs-pre.target ... ExecStartPre=/bin/systemctl --quiet is-active iscsid.service ExecStart=/sbin/iscsiadm -m node --loginall=automatic ExecStart=/lib/open-iscsi/activate-storage.sh ExecStop=/lib/open-iscsi/umountiscsi.sh ExecStop=/bin/sync ExecStop=/lib/open-iscsi/logout-all.sh ... and (systemctl edit --full iscsid.service) ... Wants=network-online.target remote-fs-pre.target Before=remote-fs-pre.target After=network.target network-online.target ... ExecStartPre=/lib/open-iscsi/startup-checks.sh ExecStart=/sbin/iscsid ExecStop=/sbin/iscsiadm -k 0 2 ... If umountiscsi.sh (it doesn't kill applications using a mount point) can't umount a mount point (from fstab generator or a mount unit) that is still being used, the logout-all.sh will fail for logging out the session of the disk being used. But this service unit would be considered stopped, allowing "iscsid.service" unit to also be shutdown (killing the iscsid daemon and leaving an opened iscsi session). This would be problematic for iscsi root disks AND for the kernel issue (comment #73), and this is being taken care by Francis Ginther (fginther) in the next iscsi SRU: https://pastebin.canonical.com/196463/ by creating an iscsi-cleanup.service that will run a script that logs out all remaining iscsi sessions (including /) right before kernel shutdown is called by systemd-shutdown like showed in comment #73. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in linux package in Ubuntu: In Progress Status in open-iscsi package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in open-iscsi source package in Xenial: In Progress Status in linux source package in Zesty: In Progress Status in open-iscsi source package in Zesty: In Progress Status in linux source package in Artful: In Progress Status in open-iscsi source package in Artful: In Progress Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1569925/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
