Watch devlink Events Live with devlink monitor

A link flaps or a firmware reporter fires, and by the time you look the evidence has gone. devlink monitor starts a live netlink listener for devlink events, so you can narrow it to the object types that matter and confirm it is waiting properly. It is read-only: the monitor does not configure a device or port. Allow about ten minutes, plus time to reproduce the hardware event you need to see.

1. Check the installed utility

This guide follows the installed iproute2 behaviour. Here the package is iproute2 6.1.0-1ubuntu6.4 and the utility reports iproute2-6.1.0. The syntax is unusual: monitor comes straight 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 release: it is rejected as an unknown option.

2. Start a monitor for every supported object

Run this as your ordinary user first:

$ devlink monitor all

The command normally prints nothing at first. It opens a devlink Netlink socket and waits for state changes, so a quiet terminal is expected and is not a sign of failure. Leave it running in one terminal while you perform the observation or reproduce the event elsewhere.

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

$ 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 has exited.

3. Select only the event class you need

Once you know what to investigate, replace all with one object list. 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, so keep monitor before them. A command such as devlink dev monitor has the wrong shape and is not the syntax documented by devlink-monitor(8).

4. Capture output without losing the live terminal

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

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

This runs until you stop it. In another terminal, watch the file grow:

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

Some events appear only when the relevant kernel driver and hardware support devlink notifications. A working listener does not guarantee that every link, firmware or driver change will show up. The monitor reports the state changes delivered through the devlink netlink interface.

$ 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 holds information you do not need to keep.

5. Stop the listener cleanly

Go back to the terminal running the monitor and press Ctrl-C once 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 it could kill an unrelated devlink command.

No sudo is normally needed to listen. If your network namespace or device policy blocks access, investigate that 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 watch for immediate stderr output. Then check that the host has a devlink-capable device:

$ devlink dev show

That 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 exit status is also useful:

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

Exact device output is host-specific.

• Monitor exits with an error: check the object spelling against the six names in the installed manual, and make sure you are in the same network namespace as the device.
• Monitor runs but prints nothing: generate a known, safe test event only through your normal hardware or driver test procedure.