Bug 390941

Summary: udevtimeout setting nullified
Product: [Fedora] Fedora Reporter: Warren Togami <wtogami>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: notting
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-18 17:35:21 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 188611    

Description Warren Togami 2007-11-19 14:23:18 EST
udevtimeout might be specified in specialized cases like embedded or thin
clients where a narrow set of hardware is used, and it is unnecessary to wait
for udevsettle.  On slow hardware this allows boot to be a few seconds faster.

udev-116-3.fc8

/sbin/start_udev:207
        /sbin/udevcontrol env STARTUP=1
        /sbin/udevtrigger
        ret=$[$ret + $?]
        wait_for_queue $(getval udevtimeout $cmdline)
        ret=$[$ret + $?]
        wait

If you specify udevtimeout=1 in /proc/cmdline, wait_for_queue returns early with
udevsettle still running in the background, which is what you want. 
Unfortunately, due to the "wait" it waits for udevsettle to finish, effectively
nullifying the effect of udevtimeout.

Shouldn't this wait be removed?  It shouldn't effect normal users because wait
would never wait as udevsettle has finished normally.

/sbin/start_udev:124
        if [ $ret -ne 0 ]; then
                echo -n "Wait timeout. Will continue in the background."
        fi
        return $ret;

Can this message be changed to be less scary sounding for users?
Perhaps, "Continuing in background."

Can this return code always be zero?  We want to avoid the scary [FAILED] in
such cases.  It did not actually fail.
Comment 1 Harald Hoyer 2007-11-20 05:13:23 EST
> Unfortunately, due to the "wait" it waits for udevsettle to finish, effectively
> nullifying the effect of udevtimeout.

wrong. udevsettle is not started in the background.
if [ $timeout -gt 0 ]; then
            /sbin/udevsettle --timeout=$timeout
...

The "wait" is for make_extra_nodes(), especially MAKEDEV.

> Can this message be changed to be less scary sounding for users?
> Perhaps, "Continuing in background."

Hmm, normally a timeout indicates that s.th. was wrong.

On thin clients, where a narrow set of hardware is used, you don't want
startudev at all. Just untar your devices.
Comment 2 Warren Togami 2007-11-20 09:42:19 EST
notting told me that we no longer support static devices.  Our initscripts has
no option to avoid start_udev.  Are we comfortable making static devs vs. udev
configurable in a future release?
Comment 3 Harald Hoyer 2007-11-20 10:39:02 EST
Hmm, I can think of an option to turn off udevtrigger. Then
/etc/udev/makedev.d/00-mydevs.nodes can be used for the static devices.
Comment 4 Harald Hoyer 2007-11-20 10:43:31 EST
> If you specify udevtimeout=1 in /proc/cmdline, wait_for_queue returns early with
> udevsettle still running in the background, which is what you want. 

Not true, udevsettle returns after the timeout, wether all devices are created
or not. So the following commands cannot be sure all devices have been created.

udevsettle returns also, if udevd has no more events in the queue (events,
triggered by the kernel and udevtrigger).
Comment 5 Bill Nottingham 2007-11-20 11:32:18 EST
(In reply to comment #2)
> notting told me that we no longer support static devices.  Our initscripts has
> no option to avoid start_udev.  Are we comfortable making static devs vs. udev
> configurable in a future release?

No. Why would you want to provide a broken setup?
Comment 6 Warren Togami 2007-11-20 12:33:04 EST
> Hmm, I can think of an option to turn off udevtrigger. Then
> /etc/udev/makedev.d/00-mydevs.nodes can be used for the static devices.

This sounds good.  Where would the option be, somewhere in /etc/sysconfig?
Comment 7 Warren Togami 2008-02-18 17:35:21 EST
Due to the refusal in Comment #5 there's no point in pursuing this any further.
 Closing.