https://bugzilla.novell.com/show_bug.cgi?id=827654
https://bugzilla.novell.com/show_bug.cgi?id=827654#c6
--- Comment #6 from Hannes Reinecke 2013-08-30 06:53:46 UTC ---
Oh, that's not that hard.
What I did for multipath was to have systemd intercept the netlink socket, used
for communication between the admin program and the daemon. If the same trick
would be applied to iscsi it would mean that each call to iscsiadm would
automatically start iscsid.
At the same time iscsid can and should be started within the initrd, so the
only thing left to be implemented is a re-exec.
The main problem we have currently is that we can only do a full restart of the
iscsid. So whenever the iscsid has to be restarted it needs to be terminated
properly, and the new instance need to re-initialize itself before it can
operate properly.
This is a rather long window, during which we cannot process any connection
failures. Which hits us particularly hard during init, as the daemon has to be
shut down from the initrd, _then_ the real init takes over, all scripts in
boot.d are executed before iscsid is finally started during rc phase.
That is a rather long time with heavy I/O going on, so it is quite likely to
hit an I/O interruption then. But iscsid isn't running. So we're stuck and
booting hangs.
With system we should be able to do a proper re-exec; if systemd would control
_all_ filedescriptors iscsid uses (even internally) then no events on these fds
would be lost during restart. So for re-exec iscsid would just have to flush
the internal queue, and do an 'execve' on the pathname of the original program.
iscsid would then startup, pull the fds from systemd, and would be ready to go.
With that the boot.iscsid-early can be dropped and iscsid can be started during
normal system boot.
-
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.