|Summary:||udevtimeout setting nullified|
|Product:||[Fedora] Fedora||Reporter:||Warren Togami <wtogami>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-02-18 22:35:21 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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?