Comment 70 for bug 1569925
Revision history for this message
| Rafael David Tinoco (rafaeldtinoco) wrote | #70 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
This is what I discovered:
This systemd issue is caused because there are iscsi connections still logged in (not because of multipath, bonding, vlans, etc). One way of reproducing this is by simply editing the open-iscsi.service unit and disabling the logout script. It will, for me in all times, cause the same hang as we are talking to.
inaddy@iscsihang:~$ sudo systemctl edit --full open-iscsi.service
...
ExecStop=
ExecStop=/bin/sync
#ExecStop=
But of course no one is doing this. So, reading logout-all you will discover that it logs out all paths but it has some caveats: ISCSI_ROOT_
Still, I wasn't using neither to reproduce so I found out something else. Disabling both systemd services:
inaddy@iscsihang:~$ systemctl list-unit-files --full | grep iscsi
iscsi.service disabled (alias for iscsid)
iscsid.service disabled
open-iscsi.service disabled
I was still able to reproduce the issue:
http://
By issuing a logout when the iscsid daemon is gone. It looks like iscsid is lost after it has died/been killed on the sessions that were previously established. If you try to login again, it will be totally lost when trying to logout, causing leftovers (opened iscsi sessions) causing systemd to hang (even not having daemons running, in this case).
I'm investigating:
- Should systemd hang on those leftovers ? Since there are caveats that explicitly allow you to leave opened sessions, for / for example, I doubt it.
- Does iscsid daemon contain a bug that causes sessions to remain un-mapped and opened if daemon is restarted without a logout of previously opened sessions ?
Now that I'm able to reproduce this at will, I'll be able to answer those questions soon.
Best,
Rafael
PS: Matt, I asked partnership program managers to reach out to understand better your future needs.