Watch Linux devlink state changes safely with devlink monitor

You will start a live netlink listener for devlink events, narrow it to useful object types, and prove that it is waiting correctly. This is a read-only observation task: the monitor does not configure a device or port. Allow about ten minutes, plus time to reproduce the hardware event you need to observe.

1. Check the installed utility

This guide uses the installed iproute2 behaviour. On this machine the package is iproute2 6.1.0-1ubuntu6.4, and the utility reports iproute2-6.1.0. The monitor syntax is unusual because monitor comes immediately after devlink, before the object list.

$ command -v devlink
/usr/sbin/devlink
$ devlink -V
devlink utility, iproute2-6.1.0

The -V option is global and prints the utility version. Do not use devlink --version with this installed release; it is rejected as an unknown option.

Checkpoint: the command exists, and its reported version is close enough to the manual you are using to make the examples meaningful.

2. Start a monitor for every supported object

Run this as your ordinary user first:

$ devlink monitor all

The command normally prints nothing immediately. It opens a devlink Netlink socket and waits for state changes, so a quiet terminal is expected rather than evidence that the command failed. Leave this process running in one terminal while you perform the observation or reproduce the event elsewhere.

The installed manual defines all as the broad monitor selection. It also lists these individual object types: dev, port, health, trap, trap-group and trap-policer. Use the broad form for an initial capture, then narrow it when the output becomes distracting.

Checkpoint: in a second terminal, confirm that the listener is still alive:

$ pgrep -af 'devlink monitor all'
12345 devlink monitor all

The process ID will differ. If pgrep finds nothing, restart the command and read any error printed at startup. A monitor that is running but receives no events is different from one that exited.

3. Select only the event class you need

Replace all with one object list when you already know what to investigate. For example, this waits for device and port changes:

$ devlink monitor dev port

For health reporting, use:

$ devlink monitor health

Object names are positional arguments to the monitor command. Keep monitor before them. A command such as devlink dev monitor is a different shape and is not the syntax documented by devlink-monitor(8).

Filtering is useful when a busy host produces unrelated notifications, but it can hide the event you are trying to find. If a narrow listener remains silent, repeat the test with all before concluding that the device generated no notification.

4. Capture output without losing the live terminal

To retain events for later inspection, redirect standard output to a new file:

$ devlink monitor all > /tmp/devlink-events.txt

This command continues running until you stop it. In another terminal, watch the file as it grows:

$ tail -f /tmp/devlink-events.txt

Some events may be printed only when the relevant kernel driver and hardware support devlink notifications. A successful listener is not a guarantee that every link, firmware or driver change will appear. The monitor reports the state changes delivered through the devlink netlink interface.

Do not redirect to a valuable existing capture with a blind >: shell redirection truncates the destination before devlink starts. Choose a new path, or use append mode if combining captures is deliberate:

$ devlink monitor all > /tmp/devlink-events-$(date +%Y%m%d-%H%M%S).txt

The timestamped name avoids replacing an earlier capture. The file is temporary diagnostic data; remove it after review if it contains information you do not need to retain.

5. Stop the listener cleanly

Return to the terminal running the monitor and press Ctrl-C after the event has been captured:

^C
$

This closes the listener without changing devlink state. If you started it in the background, identify the exact process before stopping it:

$ pgrep -af 'devlink monitor'
12345 devlink monitor all
$ kill 12345

Use the real process ID from your output. Do not use a broad pattern such as pkill devlink on a troubleshooting host, because that could terminate an unrelated devlink command. No sudo is normally required to listen. If your network namespace or device policy prevents access, investigate that access restriction rather than making a persistent privilege change.

6. Diagnose a silent or failed monitor

First separate an idle monitor from an error. Start it in the foreground and look for immediate stderr output. Then check that the host has a devlink-capable device:

$ devlink dev show

That command lists devices if the kernel and drivers expose them. An empty result means there may be no devlink device to generate events; it does not mean the monitor syntax is wrong. The command's exit status is also useful:

$ devlink dev show
$ printf 'exit status: %s\n' "$?"
exit status: 0

Exact device output is host-specific. If the monitor exits with an error, check the object spelling against the six names in the installed manual and verify that you are using the same network namespace as the device. If it stays running with no output, generate a known, safe test event only through your normal hardware or driver test procedure. Do not reset a production device merely to create sample output.