Use sysfs Safely to Inspect Linux Devices and Kernel Objects

This guide gives you a read-first workflow for exploring /sys: identify the mounted filesystem, find devices through its stable views, follow symbolic links back to the device tree, and read an attribute without changing live system state. Allow about 15 minutes. You need a Linux machine with sysfs mounted, a shell, and ordinary read access. The examples use the local sysfs(5) from Linux man-pages 6.7, installed here by package manpages version 6.7-2.

1. Confirm that sysfs is mounted

Most Linux systems mount sysfs automatically at /sys. Check the mount without modifying anything:

$ findmnt --target /sys --output TARGET,FSTYPE,SOURCE,OPTIONS
TARGET FSTYPE SOURCE OPTIONS
/sys   sysfs  sysfs  rw,nosuid,nodev,noexec,relatime

The exact options vary. The useful result is a target of /sys and a filesystem type of sysfs. If the command reports no matching mount, inspect the directory first:

$ ls -ld /sys
$ ls -A /sys

Do not mount over a populated /sys merely to make a command work. If this is a deliberately minimal environment, the documented manual form is:

# mount -t sysfs sysfs /sys

Mounting requires elevated privileges and changes the system mount table for the current boot. Prefer the machine's normal init or container configuration, and undo a manual test with sudo umount /sys only when you are certain no other process depends on that mount.

2. Learn the top-level views

List the directories rather than assuming every system exposes the same entries:

$ find /sys -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort
block
bus
class
dev
devices
firmware
fs
kernel
module
power

The installed manual describes the important relationships. /sys/devices is the kernel device tree. /sys/class groups devices by function, while /sys/block provides links for discovered block devices. /sys/bus groups bus types and exposes their devices and drivers. /sys/module contains directories for loaded modules. Some directories are optional, and virtual machines may expose different firmware or hypervisor entries.

Checkpoint: treat the convenient directories as indexes, not separate copies. Their entries are commonly symbolic links into /sys/devices. This is why a short path such as /sys/class/net/INTERFACE can lead to a much longer hardware or virtual-device path.

3. Inspect a network device without changing it

Replace INTERFACE with a name that exists on this host. The command reads directory metadata only:

$ IFACE='INTERFACE'
$ test -e "/sys/class/net/$IFACE" && readlink -f "/sys/class/net/$IFACE"
/sys/devices/virtual/net/INTERFACE

A physical interface may resolve below a PCI or USB path instead. The virtual result is normal for devices such as bridges, loopback, and some tunnel interfaces. If the test fails, list the names that are actually visible to this process:

$ printf '%s\n' /sys/class/net/* | sed 's#^/sys/class/net/##'

The /sys/class/net view is namespace-sensitive: the manual says it represents networking devices visible in the accessing process's network namespace. Do not infer host-wide inventory from a container's result.

4. Use device numbers to find a sysfs entry

For a device node, stat prints its major and minor numbers in hexadecimal with the format used by the sysfs device index:

$ stat -c '%t %T' /dev/null
1 3
$ readlink /sys/dev/char/1:3
../../devices/virtual/mem/null
$ ls -d /sys/devices/virtual/mem/null/
/sys/devices/virtual/mem/null/

Here 1:3 is the character-device major and minor pair. The link under /sys/dev/char is a lookup route, not a second device object. For a different node, use the numbers printed by stat; do not copy 1:3 unless you are deliberately inspecting /dev/null.

5. Read an attribute and check its type

Attributes are files exported by kernel subsystems. Many are read-only, and their content is defined by the owning subsystem rather than by sysfs itself. Start with metadata and a bounded read:

$ ATTR='/sys/devices/virtual/mem/null/dev'
$ test -r "$ATTR" && stat -c '%F %A %s %n' "$ATTR"
regular file -r--r--r-- 0 /sys/devices/virtual/mem/null/dev
$ od -An -c "$ATTR"
   1   :   3  \n

A zero byte count from stat does not mean the attribute is useless; generated sysfs values can be returned by the kernel when read. Use cat for a known small text attribute. Do not assume every sysfs file is text, stable across kernel releases, or available on another machine. For an interface's exact meaning, consult the owning subsystem's documentation or ABI entry.

6. Keep writes out of exploratory commands

Some sysfs attributes are writable and can change kernel variables, device behaviour, power policy, firmware-facing state, or module parameters. A successful write is not an undo record. Do not use sudo sh -c 'echo VALUE > /sys/...' as a generic test, and do not write a guessed value because a filename looks obvious.

Before any intentional write, identify the exact ABI documentation, record the current value, confirm the required privilege, and establish the recovery path. For a reversible experiment, save the original value in a private file and test during a maintenance window. If the owning documentation does not define an inverse operation, stop. Removing a module, rebooting, or remounting does not generally restore an arbitrary runtime attribute.

Reading /sys/module/MODULE/parameters can show module parameter values, but availability and writability vary. A module parameter that is writable at runtime may affect a live driver. Treat that as a service-disrupting change, not as ordinary configuration.

7. Diagnose the common traps

• Path missing: the device, driver, subsystem, namespace, or optional interface may not exist. Check the nearest parent and list its actual entries.
• Permission denied: first check the attribute mode and the process identity. Do not jump to root; privilege cannot create an absent kernel interface.
• Symlink surprises: use readlink to see the stored relative link and readlink -f to resolve it. The resolved path can change when hardware is added or removed.
• Changing output: sysfs represents live kernel state. Device discovery, hotplug, driver reloads, and power transitions can alter directory contents while you inspect them.

If an entry disappears between commands, rerun the read-only checks and capture the device's current state. Avoid scripts that rely on a directory listing remaining fixed while hardware or services are changing.