[arch-projects] [initscripts][PATCH 0/3] Minor cleanup to rc and disabling udevadm settle

[Tom Gundersen]

On Sun, Apr 24, 2011 at 3:56 PM, Dave Reisner <d at falconindy.com> wrote:
>> Why not just pass --timeout=0 to udev?
>
> The end result is the same, but explicitly passing 0 will dump the
> contents of the event queue if it's not empty.

That sounds fair enough to me. Then we will at least know that
something is not ready yet.

> This doesn't prevent uevents from being handled, it just removes an
> explicit barrier where we wait for X seconds for the queue to be
> emptied.

My concern is that uevents for block devices are handled after we try
to mount (or decrypt/assemble) them. In which case it will be as if
the uevents were not handled at all, and for the user it will not be
clear why.

> 1) Those with problematic hardware who get stuck processing this queue
> to timeout.

In case udev gets stuck waiting for something that we know it should
not wait for, they should lower the timeout. However, they should
never set it to 0, as we do need udev to wait for the things mentioned
above. Even if things boot fine today with a 0 timeout, if other
things speeds up or slow down in the future, your boot might break in
non-obvious ways.

> 2) Others with non-complicated setups who don't need to wait for udev
> to fully complete processing. They'll lose a second off their boot time,
> and no harm will come of this.

As outlined above, this would lead to a fragile system. Waiting a
second or two during boot is the cost of having a static initsystem...

Unless there are specific bugs I'm not aware of, I think that setting
the timeout to less than 5 is never the right thing to do (and less
than the default is only very rarely the right thing to do), so I
think we would mislead people if we explicitly optimize for timeout=0.

Or am I missing something?

-t

PS

To the people with broken hardware who wants to set a very low
timeout, I suggest one of the following:
1) set a reasonable timeout (5-10 seconds) and just accept a slow boot,
2) fix the underlying problem (change hardware?), or
3) change to a more advanced initsystem (systemd/upstart) that can
deal with hardware appearing and disappearing at any time (but they
are not perfect in this regard yet either, as far as I know).