From 55944e5e40b1be2afc4855d8d2baf4b73d1876b5 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 10 Apr 2024 22:49:52 +0200 Subject: Adding upstream version 255.4. Signed-off-by: Daniel Baumann --- man/systemd-udev-settle.service.xml | 51 +++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 man/systemd-udev-settle.service.xml (limited to 'man/systemd-udev-settle.service.xml') diff --git a/man/systemd-udev-settle.service.xml b/man/systemd-udev-settle.service.xml new file mode 100644 index 0000000..2852f31 --- /dev/null +++ b/man/systemd-udev-settle.service.xml @@ -0,0 +1,51 @@ + + + + + + + + systemd-udev-settle.service + systemd + + + + systemd-udev-settle.service + 8 + + + + systemd-udev-settle.service + Wait for all pending udev events to be handled + + + + systemd-udev-settle.service + + + Description + This service calls udevadm settle to wait until all events that have been queued + by udev7 have been + processed. It is a crude way to wait until "all" hardware has been discovered. Services may pull in this + service and order themselves after it to wait for the udev queue to be empty. + + Using this service is not recommended. There can be no guarantee that hardware + is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and + certain buses and devices take a very long time to become ready, and also additional hardware may be + plugged in at any time. Instead, services should subscribe to udev events and react to any new hardware as + it is discovered. Services that, based on configuration, expect certain devices to appear, may warn or + report failure after a timeout. This timeout should be tailored to the hardware type. Waiting for + systemd-udev-settle.service usually slows boot significantly, because it means waiting + for all unrelated events too. + + + + See Also + + udev7, + udevadm8 + + + -- cgit v1.2.3