Ovirt devel - Apr 2008 - Re: [Fedora-livecd-list] [PATCH] mkliveinitrd: wait for udev queue to clear before killing udevd

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.

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?
> 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.

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.
> 
> 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?
> 
>> 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.
> 
If I understand that correctly, a udevd is running in initrd, which is killed
and then normal boot with
rc.sysinit start and start_udev is called.

Since start_udev replays all events anyway, why don't you kill udevd and
remove the old queue?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20080415/98035d2c/attachment.bin>

Harald Hoyer wrote:
> If I understand that correctly, a udevd is running in initrd, which is 
> killed and then normal boot with rc.sysinit start and start_udev is called.
yes
 
> Since start_udev replays all events anyway, why don't you kill udevd
and
> remove the old queue?
Also possible solution. But shouldn't udevd, for robustness, cleanup
/dev/.udev/queue/ on its startup?