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

[Andrew Patterson]

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