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

Andrew Patterson andrew.patterson at hpe.com
Wed Jan 4 17:53:35 UTC 2017


On 01/03/2017 03:47 PM, Christian Seiler wrote:
> On 01/03/2017 10:51 PM, Andrew Patterson wrote:
>> 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.
> 
> Did you try stopping iscsiuio for longer periods of time? For
> example more than 20 minutes? I would like to know what happens
> if you hit ARP timeouts.

I ran it overnight (13 hours) with no issues.

> 
>>> 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?
> 
> It's only a couple of seconds if there's no fsck running for
> another partition. Then it could easily be minutes or even
> longer, depending on the partition size, the number of files
> and the filesystem in question.
>

Granted.

>>>>> 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.
> 
> I meant this:
> 
> https://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/
> (The @-stuff is only relevant if the binary is _not_ started
> via a systemd service.)

This only applies for systemd though. It won't help us for sysv-init
(assuming we need to care).

> 
> OTOH, since iscsiuio is apparently not required to be running
> while data is transferred, killing it at shutdown deosn't
> seem to be that big of a deal.

It seems so.

> 
>> It looks like we can use start-stop-daemon in local-top and
>> local-bottom to gracefully start and stop the daemon.
> 
> Yes, that appears to be the case.
> 
>>>>> 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?
> 
> See my request above: if after 20 minutes of iscsiuio being
> offline everything is still fine, I'd be fine with it. If it's
> less, it depends on how much less.

It looks like we are good. At least in the normal case.

> 
> That said: your initial tests are sufficient for me to upload
> a version of open-iscsi that includes support for this to
> the 'experimental' suite, so I'll do that either tomorrow or
> on Thursday, depending on when I'll find time for that. If you
> could then test this (and write down how you set this up so
> we can add it to README.Debian), and give me feedback on the
> "iscsiuio is offline for longer" test, then I'd be fine with
> uploading this to unstable so it makes it into Stretch.
>

I would be happy to test it.

> Other than #850057: does iscsistart need additional changes to
> work with iscsiuio? One would probably need to pass
> -P iface.transport_name=bnx2i -P iface.net_ifacename=eth0
> -P iface.hwaddress=aa:bb:cc:dd:ee:ff or similar, right?
>

I have been using iscsstart -b with iSCSI IBFT to bring up the
interface which seems to do all the required magic (at least for the
iscsi_auto case). If not using iscsi_auto, the local_top script wants iSCSI
login parameters on the kernel command-line.

Don't forget to define OFFLOAD_BOOT_SUPPORTED, ala:

diff --git a/debian/rules b/debian/rules
index 906132a..562ef8d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 #export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_CFLAGS_MAINT_APPEND = -Wall
+export DEB_CFLAGS_MAINT_APPEND = -Wall -DOFFLOAD_BOOT_SUPPORTED
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk


-- 
Andrew Patterson
Hewlett-Packard Enterprise



More information about the Pkg-iscsi-maintainers mailing list