On 01/03/2017 09:10 PM, Andrew Patterson wrote: >> How does the rest of the boot process proceed then? What happens >> when iscsiuio is to be started regularly at boot from the systemd >> service / init script? >> Is the iscsiuio from the initramfs required >> to be running at all times during the iSCSI session or can it be >> restarted, as long as the time during which that happens is brief >> enough? Is it required to be kept around during shutdown if it's >> on iSCSI? > > I don't believe it needs to be running to support traffic, just when > doing logins. I will test to confirm.
That would be ideal. :) As far as I can tell from skimming the source iscsiuio is also responsible for doing ARP and responding to ICMP - but even then it wouldn't be a problem for restarting in that case, as long as the MAC address of the target (or a router on the way to the target) doesn't change during restart. >> Does it follow systemd's process name convention to make >> sure systemd doesn't kill it during shutdown? >> > > I am looking into this. One thought is to start the daemon, do the > login, and then kill it. Then the normal sysvinit/upstart/systemd > scripts can restart it normally. If it's really just for logins: yes, we can do that. If it also does ARP and such, I'd rather only kill it as close to the restart as possible. But having the init script / systemd service (there was never a native upstart job for it) kill the initramfs one right before starting the own binary is easy, so if that's required then that would also be fine. It's going to be a lot trickier if we can't restart it at all. >> Before I add the aforementioned steps 1 & 2 I'd like to be sure that >> this actually works properly beyond the initramfs. So any >> information related to that would be appreciated. > > I am going to look at other package code to see how they handle daemon > startup. NFS comes to mind. NFS doesn't actually need a daemon running after the initial NFS login, at least temporarily: - NFSv3 needs the to have portmap running on the client side, so that locking works. However, you can spoof that, which is what klibc does: http://sources.debian.net/src/klibc/2.0.4-9/usr/kinit/nfsmount/README.locking/ Basically you don't need the portmapper to be running at all until and actual file lock is taken. - NFSv4 doesn't need anything running on the client side to mount with sec=sys with raw UIDs. For idmapping you can use the request-key / nfsidmap kernel upcalls instead of idmapd (which is deprecated on the client side), so nothing needs to be running there either. - NFSv4 + Kerberos needs rpc.gssd running, but I've never seen root on Kerberized NFSv4 even being advertised. (You'd also need to have credentials with which you can get a Kerberos ticket in the initramfs + the tools to get the ticket for that to work.) Regards, Christian