Udev Diagnostic Test for a Broken /dev/null Node

A misconfigured udev rule can silently break /dev/null permissions, and the system may report the node as corrupt without an obvious cause. The udevadm test command simulates rule application against a specific device path, giving you a full trace of which rules fire, what mode and ownership they set, and whether a symlink is preserved. This walkthrough shows the exact command syntax and walks through the output so you can pinpoint the offending rule.

Inspecting the Current State

Start by confirming what the kernel and filesystem actually report for the node:

[root@example ~]# ls -la /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 27 19:22 /dev/null

The mode 0666 and ownership root:root look correct here, but a custom rule in /etc/udev/rules.d/ could override these values at the next device event.

Running the udevadm Test

Use udevadm test with the device path resolved via udevadm info:

[root@example ~]# sudo udevadm test $(udevadm info -q path /dev/null)

Key Output Sections

The command prints several blocks. Here is what to focus on:

1. Trie on-disk summary - confirms the udev database is loaded and reports the file size, string count, and node count.
2. Rules file listing - every .rules file that udev reads, in order. Watch for custom files in /etc/udev/rules.d/ that appear after the vendor defaults.
3. Device handling block - the critical section for your diagnosis:

handling device node '/dev/null', devnum=c1:3, mode=0666, uid=0, gid=0
preserve permissions /dev/null, 020666, uid=0, gid=0
preserve already existing symlink '/dev/char/1:3' to '../null'
created empty file '/run/udev/data/c1:3' for '/devices/virtual/mem/null'

4. Final attribute dump - the resolved values udev would apply:

ACTION=add
DEVMODE=0666
DEVNAME=/dev/null
DEVPATH=/devices/virtual/mem/null
MAJOR=1
MINOR=3
SUBSYSTEM=mem
USEC_INITIALIZED=2507331988937

Interpreting the Results

• If DEVMODE or the uid/gid values differ from what you expect, scroll up through the rules file list and identify the last file that touched those attributes.
• The preserve permissions line means udev detected an existing node and chose not to overwrite its mode. If you see mode=0600 instead of 0666, a rule is explicitly restricting access.
• The created empty file '/run/udev/data/c1:3' line confirms the in-memory database entry was written. A missing or stale entry here can cause subsequent events to behave unexpectedly.

Next Steps

Once you identify the offending rule file, either correct the MODE, OWNER, or GROUP assignment in that file, or remove the rule if it is no longer needed. After editing, reload the rules with:

sudo udevadm control --reload-rules
sudo udevadm trigger /dev/null

Then re-run the udevadm test command to confirm the resolved attributes now match your expectations.

• Technology
• How-To

• SysAdmin
• Troubleshooting