udevadm settle timeout semantics
The manpage for udevadm (version 141) says about the timeout for settle and --timeout:
[quote]
udevadm settle [options]
Watches the udev event queue, and exits if all current events are handled.
--timeout=seconds
Maximum number of seconds to wait for the event queue to become empty. The default value is 180 seconds. A value of 0 will check if the queue is empty and always return immediately.
[/quote]
Am I reading this correctly if I assume that udevadm has to wait for an event to be "handled" regardless of the timeout value?
Example: dhclient has a default of 60 seconds to try to get an ip address until it fails. udevadm settle waits for the whole 60 seconds to pass regardless of the timeout parameter.
Is this behaviour as intended?
Thanks for the help,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 16 lines · Seewer Philippe
The manpage for udevadm (version 141) says about the timeout for settle and --timeout:
[quote]
udevadm settle [options]
Watches the udev event queue, and exits if all current events are handled.--timeout=seconds
Maximum number of seconds to wait for the event queue to become empty. The default value is 180 seconds. A value of 0 will check if the queue is empty and always return immediately.
[/quote]
Quoted 8 lines
Am I reading this correctly if I assume that udevadm has to wait for an event to be "handled" regardless of the timeout value?
Example: dhclient has a default of 60 seconds to try to get an ip address until it fails. udevadm settle waits for the whole 60 seconds to pass regardless of the timeout parameter.
Is this behaviour as intended?
The timeout is the maximum to wait:
$ echo 'RUN+="/bin/sleep 300"' > /etc/udev/rules.d/00.rules $ echo add > /sys/class/mem/zero/uevent
$ time udevadm settle --timeout=3 udevadm settle - timeout of 3 seconds reached, the event queue contains: /sys/devices/virtual/mem/zero (1796)
Not sure, udev 141 maybe had a bug here.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1245327385.7315.3.camel-2/[email protected]
Quoted 24 lines · Kay Sievers
Quoted 15 lines · Seewer Philippe
The manpage for udevadm (version 141) says about the timeout for settle and --timeout:
[quote]
udevadm settle [options]
Watches the udev event queue, and exits if all current events are handled.--timeout=seconds
Maximum number of seconds to wait for the event queue to become empty. The default value is 180 seconds. A value of 0 will check if the queue is empty and always return immediately.
[/quote]Quoted 5 lines
Am I reading this correctly if I assume that udevadm has to wait for an event to be "handled" regardless of the timeout value?
Example: dhclient has a default of 60 seconds to try to get an ip address until it fails. udevadm settle waits for the whole 60 seconds to pass regardless of the timeout parameter.
Is this behaviour as intended?
The timeout is the maximum to wait:
Quoted 8 lines
$ echo 'RUN+="/bin/sleep 300"' > /etc/udev/rules.d/00.rules $ echo add > /sys/class/mem/zero/uevent$ time udevadm settle --timeout=3 udevadm settle - timeout of 3 seconds reached, the event queue contains: /sys/devices/virtual/mem/zero (1796)Not sure, udev 141 maybe had a bug here.
That is correct.
$ echo 'KERNEL=="zero" RUN+="/bin/sleep 300"' > /etc/udev/rules.d/00.rules $ echo add > /sys/class/mem/zero/uevent
$ time udevadm settle --timeout=5 real 2m52.687s user 0m0.004s sys 0m0.064s
Harald found the bugfix for udevadm which fixed this:
http://article.gmane.org/gmane.linux.hotplug.devel/13952
This creates a problem for network configuration: If dhcp takes longer than 30 seconds plus the time we allow for mount fall-through, an emergency-shell will appear while maybe mount is happending in the background because dhcp succeeded.
Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Seewer Philippe
This creates a problem for network configuration: If dhcp takes longer than 30 seconds plus the time we allow for mount fall-through, an emergency-shell will appear while maybe mount is happending in the background because dhcp succeeded.
Any thoughts?
Network booting likely needs to retry DHCP and NFS/netroot mounts if they timeout during boot. Booting a large cluster can cause these timeouts to occur if they overload the server and it's a real PITA to find the machines that didn't boot properly and reboot them. --
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html