[Fedora-livecd-list] [PATCH] mkliveinitrd: wait for udev queue to clear before killing udevd

[Jeremy Katz]

On Tue, 2008-04-15 at 10:35 +0200, Alan Pevec wrote:
> Jeremy Katz wrote:
> > On Tue, 2008-04-15 at 00:51 +0200, Alan Pevec wrote:
> >> mkliveinitrd: wait for udev queue to clear before killing udevd
> >>
> >> udevd doesn't seem to cleanup on kill, so let it clear events from /dev/.udev/queue/
> >>
> >> Or should this be filed as udevd bug (cleanup .udev/queue/ on startup and/or kill) ?
> > 
> > We've already done one udevsettle for 30 seconds -- how does this any
> > more guarantee that things are cleared?  I suspect this should probably
> 
> We do dmsetup etc. in the meantime so more udev events appear. And if all is good, it won't hang 30 sec, it continues immediately.

There's no guarantee that 30 seconds is enough, though.

> btw, we have unconditional 5s sleep here: http://git.fedorahosted.org/git/?p=mkinitrd;a=blob;f=mkliveinitrd;h=84fcc8036d47613e33c6f3c79003900ae7b6fcae;hb=HEAD#l653
> Can we remove that?

I'd rather not -- it's the only time and way that anyone can tell
whether they're using a persistent or a temporary overlay right now.
Longer term, I'd like to integrate something better into the desktop
session, but that's less easy to do than might be hoped.

> > be handled in udev.  But what exactly are you seeing as the symptom?
> 
> start_udev after switching root times out (after default 180s) on its udevsettle and after boot is finished, I still see an event /devices/virtual/block/dm-1 in exported queue /dev/.udev/queue/ - I assume this is b/c we killed previous instance of udevd before event could be cleared.
> It's a race condition - for me it shows up when PXE booting oVirt liveCD (created with livecd-iso-to-pxeboot), never when booting the same ISO directly (both F9 KVM guests on F8 host). If I add eshell, which pauses just before killing udevd, event is cleared.
> 
> I agree this might be seen as a workaround but killing udevd just like that doesn't seem polite.
> Then again udevd should prolly clear its exported queue on startup, so I'm CCing Harald to weigh in.

This really feels like the better answer.  It's not going to leave the
possibility that 30 seconds isn't long enough

Jeremy