[Pkg-iscsi-maintainers] Bug#850060: open-iscsi initramfs scripts do not start up iscsiuio deamon

[Christian Seiler]

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