Bug 390941 - udevtimeout setting nullified
Summary: udevtimeout setting nullified
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: K12LTSP
TreeView+ depends on / blocked
 
Reported: 2007-11-19 19:23 UTC by Warren Togami
Modified: 2008-02-18 22:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-18 22:35:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Warren Togami 2007-11-19 19:23:18 UTC
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 10:13:23 UTC
> 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 14:42:19 UTC
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 15:39:02 UTC
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 15:43:31 UTC
> 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 16:32:18 UTC
(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 17:33:04 UTC
> 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 22:35:21 UTC
Due to the refusal in Comment #5 there's no point in pursuing this any further.
 Closing.


Note You need to log in before you can comment on or make changes to this bug.