initqueue

To move all "big" jobs out of the udev event handling, I introduce the "initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be fast, in case udev supports "udevadm settle --exit-if-exists="

Harald Hoyer wrote:

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

It works, except if a udev event takes longer than the default 180s as is the case with an unpatches cryptsetup and/or if we do user-interaction from within udev which we shouldn't do anyway.

Thank you,
Philippe

modules.d/99base/init +0 -0

index 27c4dad..e14dc20 100755
@@ -46,6 +46,11 @@ mkdir /dev/shm

mkdir /dev/pts
mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts >/dev/null 2>&1

modules.d/99base/init +5 -0

+# Set version specific udevadm options
+UDEVVERSION=$(udevadm --version)
+UDEVADMOPTS=""
+[ $UDEVVERSION -ge 143 ] && UDEVADMOPTS="--exit-if-exists=$NEWROOT/proc"
+

# run scriptlets to parse the command line
getarg 'rdbreak=cmdline' && emergency_shell
source_all cmdline

modules.d/99base/init +0 -0

@@ -76,7 +81,7 @@ source_all pre-trigger
 
 # then the rest

udevadm trigger $udevtriggeropts >/dev/null 2>&1

modules.d/99base/init +1 -1

-udevadm settle --timeout=30 >/dev/null 2>&1
+udevadm settle --timeout=30 $UDEVADMOPTS >/dev/null 2>&1

# pre-mount happens before we try to mount the root filesystem,
# and happens once.

modules.d/99base/init +0 -0

@@ -86,18 +91,23 @@ getarg 'rdbreak=mount' && emergency_shell
 
 # mount scripts actually try to mount the root filesystem, and may
 # be sourced any number of times. As soon as one suceeds, no more are

sourced.

modules.d/99base/init +12 -7

-i=0
-while :; do
-    [ -d "$NEWROOT/proc" ] && break;
-
+while [ ! -d "$NEWROOT/proc" ] ; do
    for f in /mount/*.sh; do
       [ -x "$f" ] && . "$f";
       [ "$ROOTFS_MOUNTED" ] && break;
    done
 
-    sleep 0.5
-    i=$(($i+1))
-    { flock -s 9 ; [ $i -gt 20 ] && emergency_shell; } 9>/.console_lock
+    # If the queue was empty and mount scripts failed as well, bail out
+    [ -n "$EMPTYQUEUE" ] && break;
+
+    # Give udev events some time before we try anything. If the queue
+    # is empty, give mount-scripts another chance to get the root
+    udevadm settle --timeout 5 $UDEVADMOPTS && EMPTYQUEUE="1"
+done
+
+# udev queue is empty, no root? Let the user figure this out
+while [ ! -d "$NEWROOT/proc" ] ; do
+    { flock -s 9 ; emergency_shell; } 9>/.console_lock

done

# pre pivot scripts are sourced just before we switch over to the new root.

Hi all,

Quoted 1 line · Seewer Philippe

Harald Hoyer wrote:

[ .. ]

Quoted 7 lines

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

D'accord.

Ah, if it were so easy.

This approach work perfectly for any device which does synchronous scanning.

For a device doing asynchronous scan you're out of luck here as the device might start spitting out udev events at any time, even after the udev queue is empty.

EG usb or qla2xxx have a habit of doing so. So either you implement checks for each device (-type) which detects if the device is still scanning or you indeed just wait until the device appears.

There actually is no problem with the latter, as all the design goal here is to have _every_ device initialization in the background / asynchronously by udev.
So in foreground we indeed just have to wait for the device node to appear. Even the udev queue check is pointless here; either we have a device node, in which case we can continue regardless of how many events are still in the udev queue;
or we don't have one, in which case it quite irrelevant if udev has still events to process or not.

Quoted 15 lines · Harald Hoyer

To move all "big" jobs out of the udev event handling, I introduce the "initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

Quoted 8 lines

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be fast, in case udev supports "udevadm settle --exit-if-exists="

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

It works, except if a udev event takes longer than the default 180s as is the case with an unpatches cryptsetup and/or if we do user-interaction from within udev which we shouldn't do anyway.

Thank you,
Philippe

Quoted 37 lines · Seewer Philippe

Quoted 16 lines · Harald Hoyer

To move all "big" jobs out of the udev event handling, I introduce the "initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

Quoted 8 lines

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be fast, in case udev supports "udevadm settle --exit-if-exists="

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

It works, except if a udev event takes longer than the default 180s as is the case with an unpatches cryptsetup and/or if we do user-interaction from within udev which we shouldn't do anyway.

Quoted 3 lines

Thank you,
Philippe

Well, you could remove the initqueue for ifup events, but I would like to keep it at least for cryptsetup.

Quoted 43 lines · Harald Hoyer

Quoted 41 lines · Seewer Philippe

Quoted 16 lines · Harald Hoyer

To move all "big" jobs out of the udev event handling, I introduce the "initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

Quoted 8 lines

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be fast, in case udev supports "udevadm settle --exit-if-exists="

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

It works, except if a udev event takes longer than the default 180s as is
the case with an unpatches cryptsetup and/or if we do user-interaction from within udev which we shouldn't do anyway.

Thank you,
Philippe

Quoted 2 lines

Well, you could remove the initqueue for ifup events, but I would like to keep it at least for cryptsetup.

Why not just put cryptsetup back into mountscripts as I've suggested before?

Quoted 45 lines · Seewer Philippe

Quoted 44 lines · Harald Hoyer

Quoted 42 lines · Seewer Philippe

Quoted 17 lines · Harald Hoyer

To move all "big" jobs out of the udev event handling, I introduce the "initqueue". This prevents the job from being killed by udev timeouts.

See
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut;a=commit;h=eab677a2164bccb3990487dc5ef4549b30cb1055

for the patch.

Basically inside a udev event, you don't do

RUN+="/sbin/ifup $env{INTERFACE}"

you now queue this in the initqueue with:

Quoted 8 lines

RUN+="/sbin/initqueue /sbin/ifup $env{INTERFACE}"

Inside init all jobs are worked on in serial order by the do_initqueue() function.

Now we have no more side effects due to the parallel nature of udev and still be fast, in case udev supports "udevadm settle --exit-if-exists="

Please don't do that. That way we actually loose the benefit of doing as much in parallel as possible. Instead please consider the patch below. I've been fiddling with this for a few weeks now. It basically replaces the current "wait-for-root" loop with a loop that queries the udev-queue and only exits if either root is available or all udev events have been processed.

It works, except if a udev event takes longer than the default 180s as is
the case with an unpatches cryptsetup and/or if we do user-interaction from within udev which we shouldn't do anyway.

Thank you,
Philippe

Quoted 6 lines

Quoted 2 lines

Well, you could remove the initqueue for ifup events, but I would like to keep it at least for cryptsetup.

Why not just put cryptsetup back into mountscripts as I've suggested before?

Because so much more can be inside the crypto partition, which might need further processing.

Quoted 6 lines

Quoted 3 lines

Why not just put cryptsetup back into mountscripts as I've suggested before?

Because so much more can be inside the crypto partition, which might need further processing.

That is correct. But if it's in mountscripts, it would fire more udev-events which are caught again by udevadm settle. I don't see a problem there.

Quoted 7 lines · Seewer Philippe

Quoted 6 lines

Quoted 3 lines

Why not just put cryptsetup back into mountscripts as I've suggested before?

Because so much more can be inside the crypto partition, which might need further processing.

Quoted 3 lines

That is correct. But if it's in mountscripts, it would fire more udev-events which are caught again by udevadm settle. I don't see a problem there.

Hmm, we maybe should think of merging pre-mount and mount. pre-mount makes no sense, if mounting is done inside udev rules.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines · Harald Hoyer

Quoted 8 lines · Seewer Philippe

Quoted 5 lines

Quoted 3 lines

Why not just put cryptsetup back into mountscripts as I've suggested before?

Because so much more can be inside the crypto partition, which might need further processing.

That is correct. But if it's in mountscripts, it would fire more udev-events which are caught again by udevadm settle. I don't see a problem there.

Quoted 2 lines

Hmm, we maybe should think of merging pre-mount and mount. pre-mount makes no sense, if mounting is done inside udev rules.

I would like to chime in again with the longstanding race condition inherent in having resume from hibernate and root fs mounting as udev rules.

Right. Maybe we really should not mount from udev rules, and only generate a /mount script or set a symlink to /dev/root.