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

[Dave Reisner]

On Sun, Apr 24, 2011 at 02:24:08PM +0200, Tom Gundersen wrote:
> On Sun, Apr 24, 2011 at 3:01 AM, Dave Reisner <d at falconindy.com> wrote:
> > This is mostly for the first patch, which allows setting UDEV_TIMEOUT=0 to
> > prevent 'udevadm settle' from being called. Looking back historically, this
> > seems to cause a lot of grief with a lot of hardware. Googling turns up things
> > such as...
> >
> > https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/387086
> > https://bugzilla.redhat.com/show_bug.cgi?id=585527
> > http://lkml.org/lkml/2011/4/12/538
> > https://bbs.archlinux.org/viewtopic.php?id=117481
> 
> Why not just pass --timeout=0 to udev? Does that not work (from the
> discussions I got the impression it  should)? It should check the
> queue and return immediately, so basically the same as not calling
> udevadm at all. It seems like a reasonable workaround for those who
> need it.

The end result is the same, but explicitly passing 0 will dump the
contents of the event queue if it's not empty.

> 
> > So, we're looking at both recent and less recent. Moreover, most people
> > won't miss this if its disabled, as it's really just acting as a barrier
> > for coldplug events to complete processing. As long as it's optional and
> > documented, I think this is a reasonable thing to do.
> 
> I think it is wrong to say that most people will not miss this. We are
> not able to deal with devices that appear after udevsettle, so if the
> timeout is too short some drives might not get mounted.
> 
> I think we could support this as a hack for people who are hit by the
> bugs you describe (if just passing --timeout=0 does not work), but we
> should not give the impression that this is a proper fix (if ever the
> timeout is reached it means something is broken...).

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. Also, there's really 2 groups of people who benefit:

1) Those with problematic hardware who get stuck processing this queue
to timeout.
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.

My intention was never to advertise this as a fix for anything, which is
why I didn't document it as such in rc.conf.

d