The Linux kernel reports device changes to user space through uevents. On many current distributions, systemd-udevd processes those events using udev rules and a device database. Together with kernel-populated devtmpfs, this produces the ownership, permissions, properties, and symbolic links applications see around /dev.
Devices · Lesson 5
udev
Learn how udev processes kernel device events to apply policy, permissions, and persistent links.
From Kernel Event to Device Policy
When a device is added, changed, moved, or removed, udev can:
- read attributes from sysfs and event properties
- apply owner, group, and mode policy to a device node
- add stable symbolic links such as
/dev/disk/by-id/... - tag devices for other services
- run narrowly defined helper processing
The kernel remains responsible for the actual device and its driver. Deleting a node from /dev does not physically remove hardware, and manually creating a node with mknod does not make unsupported hardware exist or bind a driver.
What normally triggers udev processing for a device change?
Rule Locations and Precedence
Rules commonly reside in:
/usr/lib/udev/rules.d/for vendor or package-provided rules/run/udev/rules.d/for volatile runtime rules/etc/udev/rules.d/for local administrator policy
Files are processed in lexical filename order, with same-named files in higher-priority directories replacing lower-priority versions according to the installed udev implementation. Local rules should use a deliberate filename and match stable properties rather than enumeration names.
A rule can affect every matching device, so test scope carefully. Do not edit packaged rules directly when a local override or supplementary rule is appropriate.
Which directory is intended for persistent local administrator udev rules?
Inspecting a Device with `udevadm`
Query udev properties for an existing node:
$ udevadm info --query=all --name=/dev/sda
Use a node that exists on the current system. udevadm info --attribute-walk --name=... can display attributes along the sysfs parent chain, which helps construct a rule. udevadm monitor --kernel --udev --property observes kernel and processed events; it may expose device identifiers, so handle captured output appropriately.
What does udevadm info --query=all --name=/dev/sda request?
Applying Rule Changes Carefully
Reloading rule files affects future event processing; it does not automatically reconstruct every existing device state. Triggering events manually can affect many devices and services, so narrow the target and use the installed udevadm documentation. A testing command can simulate rule evaluation but may not reproduce every real event side effect.
Back up local rules, validate syntax, observe one known test device, and keep a recovery path before changing permissions or names. Avoid long-running work directly in udev event processing; delegate it to an appropriate service.
What does reloading udev rules primarily change?
Use Explore Hardware Devices in Linux to correlate udevadm properties, sysfs paths, and /dev links in a controlled environment.
Lesson complete
You finished udev
You can now place udev between kernel events and user-space device policy.
Relate uevents and sysfs attributes to udev rule matching.
Separate vendor, runtime, and local rule locations.
Inspect properties and event flow with
udevadm.Reload and trigger rules only with a narrow, tested scope.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account