Use systemd-udev-settle Carefully at Boot

A boot that hangs for no obvious reason often means a service is waiting on hardware udev has not finished probing. systemd-udev-settle.service is the blunt fix people reach for first. You will finish with a bounded way to wait for the current udev queue, a way to inspect the unit that provides the wait, and a clear decision about whether you should use it at all. The examples were checked against systemd 255.4-1ubuntu8.17 on this machine. The service is a compatibility mechanism, not a guarantee that every device has been discovered.

Allow about ten minutes. You need a shell and systemd-udev; inspecting the unit and running udevadm settle are ordinary operations. Starting the system service needs root and can delay boot or another service, so keep that step for a dependency that genuinely requires it.

1. Check the installed unit before using it

Read the unit that is actually installed. This avoids confusing the service name with a command that continually monitors hardware:

$ systemctl cat systemd-udev-settle.service
[Service]
Type=oneshot
TimeoutSec=180
RemainAfterExit=yes
ExecStart=udevadm settle

On this system the unit loads from /usr/lib/systemd/system/systemd-udev-settle.service. It starts udevadm settle once, has a 180-second service timeout, and stays marked active after the command completes. It does not watch for devices that appear later.

Checkpoint: confirm the unit's installation state without changing anything.

$ systemctl is-enabled systemd-udev-settle.service
static

static means there is no normal enablement workflow for this unit. It is meant to be pulled in by another unit when a legacy dependency needs it. Do not enable it at boot as a general-purpose hardware readiness switch.

2. Test the wait directly with a limit

For troubleshooting, call the underlying command directly and choose a timeout that suits the check:

$ udevadm settle --timeout=10
$ status=$?
$ printf 'udev settle status: %s\n' "$status"
udev settle status: 0

The installed udevadm accepts --timeout=SEC. With no pending events, this machine returns immediately with status 0. With events still pending, the command waits up to the requested limit. Treat the status as the result and investigate a non-zero one against the device and boot logs; a short wait completing does not prove a particular device exists.

• Use a small limit while diagnosing a slow boot. It makes the delay visible and keeps an accidental test from waiting for the full 180 seconds.
• Know what the wait covers. It only waits for queued udev work. It does not create a device node, load a driver on demand, or make asynchronous kernel hardware detection synchronous.

Checkpoint: confirm the exact options on the installed version.

$ udevadm settle --help
udevadm settle [OPTIONS]

Wait for pending udev events.

  -t --timeout=SEC          Maximum time to wait for events
  -E --exit-if-exists=FILE  Stop waiting if file exists

3. Use the service only for a real dependency

If a unit has a demonstrated dependency on the legacy settle point, start it explicitly as root:

$ sudo systemctl start systemd-udev-settle.service
$ systemctl is-active systemd-udev-settle.service
active

The first command may wait up to the unit's configured 180 seconds. The second is an ordinary read-only check, though it can report inactive if the start failed or the unit never ran. For a successful oneshot run, active reflects RemainAfterExit=yes, not a background process still handling events.

Warning: this is a service-disrupting wait. It can hold up a boot transaction while unrelated devices finish probing. Do not add it to a unit merely because a device was absent once during testing. Make the dependent unit order itself after this service only when its design cannot cope with devices arriving asynchronously.

If you started it for a test and want to clear its active state, stop the oneshot unit:

$ sudo systemctl stop systemd-udev-settle.service
$ systemctl is-active systemd-udev-settle.service
inactive

Stopping this unit does not undo kernel discovery and does not remove device nodes. It only clears the service state. If another unit still requires it, systemd may start it again as part of that transaction.

4. Prefer an event or a tailored timeout

The service's central limitation is timing. The kernel detects hardware asynchronously, some buses take a long time to become ready, and new hardware can appear at any point. An empty queue is only a snapshot, not proof that every device your application cares about is present.

• A service that can react to devices should subscribe to udev events or use the device unit and dependency mechanisms suited to its design.
• A service that expects one configured device should wait for that device, or fail after a timeout chosen for that hardware, giving operators a useful failure instead of a delayed boot.

A common mistake is treating systemd-udev-settle.service as a repair command. It is not. If the queue stays busy, inspect the events and the service generating them. If the expected device is missing, inspect kernel messages, driver loading and the device's own unit or configuration. Increasing a broad settle delay only hides the cause and slows boot further.

Done means

• You inspected the installed unit and confirmed its 180-second timeout and oneshot behaviour.
• You tested udevadm settle with an explicit timeout and captured its status.
• You know that static is expected for the unit, not a reason to enable it globally.
• You will use the service only for a proven legacy dependency, preferring a device-specific event or timeout for new work.