#686595 "implement an event based LUN detection mechanism"

Package:
open-iscsi
Source:
open-iscsi
Description:
iSCSI initiator tools
Submitter:
Peter Gervai
Date:
2025-08-17 17:47:47 UTC
Severity:
wishlist
Tags:
#686595#5
Date:
2012-09-03 17:02:30 UTC
From:
To:
My devices reside on multiple hosts using all kinds of troublesome parameters (drbd, slow links, virtualised machines, etc)
which results 2-3 seconds between iscsi login and the devices recognised by the kernel. open-iscsi start script wasn't
quite patient, declared no vg's available (in fact no pv's at the point of time), and failed to mount the whole
shebang.

This patch make it a bit more patient, trying 10 times 1 second to get it done. These parameters could be
configured, changed etc., it is just good for the average around me. Should not hurt anyone I guess, unless
I screwed up the script, which is quite possible.

Thanks,
Peter


diff -r f060bdd7bf69 init.d/open-iscsi
--- a/init.d/open-iscsi Mon Sep 03 18:27:47 2012 +0200
+++ b/init.d/open-iscsi Mon Sep 03 18:53:13 2012 +0200
@@ -117,7 +117,13 @@
                log_daemon_msg "Activating iSCSI volume groups"
                for vg in "$LVMGROUPS"; do
                        log_progress_msg $vg
-                       vgchange --available=y $vg
+                       for try in `seq 1 10`; do
+                               if vgchange --available=y $vg; then break; fi
+                               log_daemon_msg "$vg is not yet available, waiting 1 second... (try $try)"
+                               # you may have to raise repeat and sleep if your dev syncronises even slower
+                               sleep 1;
+                       done
+
                done
                log_end_msg 0
        fi
#686595#10
Date:
2012-09-04 17:03:58 UTC
From:
To:
The patch looks okay to me. But I am not sure which way we want to go. A
better approach could be to use a udev rule. Also someone needs to test
this scenario with the newer event based init daemons.
#686595#15
Date:
2012-09-04 19:53:07 UTC
From:
To:
fails, and it's been failing in the last year or so. Yesterday was the day I
was able to spend a few hours on testing and finalising.

I'm not against udev rules but I didn't master 'em so I don't want to mess
around it.

Which init do you particularly have in mind? I can install anything on my test
VMs until I send them to oblivion. :-) [I'll check them though.]

peter
#686595#20
Date:
2012-09-05 05:49:00 UTC
From:
To:
systemd seems to have the most interest right now.
#686595#25
Date:
2012-09-05 13:14:05 UTC
From:
To:
Interesting; popcon says systemd 600+ installed while systemd-sysv is
around 70; this is versus upstart 250 installs. I'll try to check
them.

Peter
#686595#30
Date:
2012-09-05 17:02:33 UTC
From:
To:
I guess most are still passing it as the kernel argument and exploring
it. No one wants a broken init.
#686595#35
Date:
2012-09-05 17:43:08 UTC
From:
To:
Probably.

Upstart works and requires the patch, but as far as I see it's not
really upstarty: it closely emulates sysvinit and doesn't do neither
event driven runs nor parallel processing, so no surprise here.

For systemd I have to pull up to sid the test system...

Peter
#686595#40
Date:
2012-09-05 17:47:26 UTC
From:
To:
The current init script will show you no difference even when run with
systemd. What you need is to write a systemd .service for open-iscsi
that should honor events and call helper applications (in this case
vgchange).
#686595#45
Date:
2012-09-05 18:26:36 UTC
From:
To:
By the current explanation of 'settle' command in the manpage, ideally
it should wait. But it does not.

   udevadm settle [options]
       Watches the udev event queue, and exits if all current events are
handled.