Tune and Troubleshoot systemd-udevd Safely

systemd-udevd is the daemon that turns a raw kernel device event into a working device node. A bad rule in the chain can leave a drive silently missing. You will finish with a safe way to inspect it, test its live controls, and plan a persistent setting in /etc/udev/udev.conf. The examples use systemd 255, supplied by the installed udev package on this machine. Allow about 20 minutes. You need a shell; some checks use sudo, but read-only inspection does not.

systemd-udevd listens for kernel device events and applies matching udev rules. It is normally socket-activated:

• systemd-udevd-kernel.socket receives kernel events.
• systemd-udevd-control.socket accepts control messages.

Treat changes here as service changes: a bad rule, a stopped execution queue or an aggressive timeout can delay device setup.

1. Confirm the daemon and installed version

Start with ordinary, read-only checks. This tells you which binary and unit are actually in use:

$ udevadm --version
255
$ systemctl status systemd-udevd.service --no-pager
● systemd-udevd.service - Rule-based Manager for Device Events and Files
   Loaded: loaded (.../systemd-udevd.service; static)
   Active: active (running) ...
   TriggeredBy: ... systemd-udevd-kernel.socket
                ... systemd-udevd-control.socket

The exact timestamps, paths and process count vary. A static unit is not enabled in the usual sense, so do not try to fix its status with systemctl enable. Check the two sockets named by your own output.

$ systemctl --no-pager --full status systemd-udevd.service
$ journalctl -u systemd-udevd.service -b --no-pager

2. Check the daemon's control surface

Ask the installed tool for its exact options. This avoids copying a command meant for a different systemd release:

$ udevadm control --help
udevadm control OPTION

  -e --exit                Instruct the daemon to cleanup and exit
  -l --log-level=LEVEL     Set the udev log level for the daemon
  -s --stop-exec-queue     Do not execute events, queue only
  -S --start-exec-queue    Execute events, flush queue
  -R --reload              Reload rules and databases
     --ping                Wait for udev to respond to a ping

The help output also lists --children-max, --property and --timeout. Runtime controls go to the running daemon through its control socket. They are not a replacement for editing rules, and they do not make an invalid rule correct.

Run a harmless liveness check next. It does not reload rules or change the queue:

$ udevadm control --ping
$ printf 'udevd ping status: %s\n' "$?"
udevd ping status: 0

If this fails, inspect the service and both sockets. Do not jump straight to --exit: that deliberately asks the daemon to clean up and exit, and device event handling may be affected while it is absent.

3. Raise logging briefly while investigating

For a short diagnostic window, raise the running daemon's log level:

$ sudo udevadm control --log-level=debug
$ udevadm control --ping
pong

The first command needs elevated privileges because it changes daemon state; the ping does not. Watch the journal for the extra detail:

$ journalctl -u systemd-udevd.service -b -f

Stop the follow mode with Ctrl-C. Debug logging is noisy, so return to the normal level once you are done:

$ sudo udevadm control --log-level=info
$ udevadm control --ping

This is a live setting only. For the same level after a future daemon start, set udev_log=info or udev_log=debug in the configuration file and arrange a controlled service restart. Do not leave debug logging enabled without a reason.

4. Reload rules without replaying every device

After changing a rule file, ask udevd to reload its rules and databases:

$ sudo udevadm control --reload
$ udevadm control --ping
pong

Reloading is not the same as replaying existing events. It only refreshes what the daemon uses for later event processing; it does not mean every existing device has been reprocessed. Test the specific device and event path you are investigating with the relevant udev tooling.

5. Know the persistent settings before you edit them

The main configuration file is /etc/udev/udev.conf. Empty lines and lines starting with # are ignored. On this installation it holds commented defaults:

#udev_log=info
#children_max=
#exec_delay=
#event_timeout=180
#timeout_signal=SIGKILL
#resolve_names=early

What each key does:

• udev_log accepts numerical syslog priorities or err, info and debug.
• children_max limits events executed in parallel. Unset, or 0, lets system resources set the ceiling.
• exec_delay delays each RUN{program} action, mainly a debugging aid.
• event_timeout defaults to 180 seconds; an event is killed after that.
• timeout_signal defaults to SIGKILL, sent on worker timeouts.
• resolve_names defaults to early: late resolves names per event, never leaves devices owned by root.

Do not edit this file casually. resolve_names=never changes ownership behaviour, and a low children_max or short event_timeout can make device setup look hung or incomplete. Back it up first:

$ sudo cp -a /etc/udev/udev.conf /etc/udev/udev.conf.before-udevd-change
$ sudoedit /etc/udev/udev.conf

$ sudo cp -a /etc/udev/udev.conf.before-udevd-change /etc/udev/udev.conf

Restoring the file is reversible, but it does not undo an event already processed with the bad setting. Check the daemon and journal after recovery.

Common traps

--stop-exec-queue is useful when you deliberately need events queued without their actions executing. It is also an easy way to make a host look broken, so do not use it as a generic pause button:

$ sudo udevadm control --stop-exec-queue
$ sudo udevadm control --start-exec-queue

The second command resumes execution and flushes the queue. If you inherit a host with a queue suspected to be stopped, run the start command only after checking why it was stopped and whether queued actions are safe to release.

• Raising event_timeout to hide a failing rule or driver. Find the slow event in the journal first.
• Changing --children-max without recording the old value. Concurrency changes load and ordering pressure, so test it during a maintenance window.