On 01/03/2017 01:27 PM, Christian Seiler wrote: > 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. :)
I tried running a load with a data integrity check while starting and stopping iscsiuio numerous times. I did not see any issues either with performance or data integrity. > > 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. > It this likely to be an issue in the one or two seconds between transitioning between the initramfs and sysvinit/systemd? >>> Does it follow systemd's process name convention to make >>> sure systemd doesn't kill it during shutdown? >>> I don't see any special handling of iscsiuio in systemd shutdown. Here is the service file: [Unit] Description=iSCSI userspace offloading daemon (iscsiuio) Documentation=man:iscsiuio(8) Documentation=file:///usr/share/doc/iscsiuio/README.gz Wants=network.target Before=iscsid.service After=network.target DefaultDependencies=no Conflicts=shutdown.target Before=shutdown.target [Service] Type=forking PIDFile=/run/iscsiuio.pid ExecStart=/sbin/iscsiuio [Install] WantedBy=sysinit.target >> >> 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 looks like we can use start-stop-daemon in local-top and local-bottom to gracefully start and stop the daemon. > > 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. >> Is my current testing enough or do we need to do more? If the later, what sort of test would you like me to run? >> 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: > NFS for the initramfs is only used in client mode, so this was a red herring. > - 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 > -- Andrew Patterson Hewlett-Packard Enterprise