Inspect TIPC Sockets Safely with tipc socket list

You will inspect the TIPC sockets, also called TIPC ports, currently visible to the kernel with one read-only command. The useful result is a list of socket identifiers and their names or peers. If TIPC is not available on this host, you will get a clear failure status instead of mistaking an empty screen for an empty socket table.

These examples use the iproute2 package version 6.1.0-1ubuntu6.4 and its installed tipc-socket(8) and tipc(8) documentation. Allow about ten minutes. You need a shell and a Linux kernel with the TIPC netlink interface available. The inspection itself normally needs no elevated privileges.

1. Confirm the command you will run

tipc-socket is the name of the manual page, not the executable you type. The command belongs to the tipc administrative tool, with socket as its first subcommand and list as the socket operation.

$ command -v tipc
/usr/sbin/tipc
$ dpkg-query -W -f='${Package} ${Version}\n' iproute2
iproute2 6.1.0-1ubuntu6.4

If command -v prints nothing, install the distribution package that supplies tipc using your normal software process. Do not substitute a similarly named third-party utility: option handling and output are specific to iproute2.

2. List the visible TIPC sockets

Run the list operation as your ordinary user:

$ tipc socket list

A successful command returns status zero and prints the socket information available from the kernel. The local manual page describes a TIPC socket as an unsigned integer. A bound socket has a logical TIPC port name associated with it. A connected socket represents a direct point-to-point connection to another socket.

The exact rows depend on the applications and TIPC topology on the host, so do not copy a made-up sample into a monitoring rule. If the command completes successfully, the shell status is zero. Capture that status immediately if a script needs to distinguish success from failure:

$ tipc socket list
$ status=$?
$ printf 'tipc socket list exit status: %s\n' "$status"

3. Read the two states that matter

Start with the port identifier, then identify whether the row describes a bound or connected socket. A bound socket has a logical name that local or clustered applications can use. A connected socket is already tied directly to another socket.

For a connection made through logical port name Y to socket identifier X, the manual page says the relationship is displayed in the form connected to X via Y. Treat those values as observations, not configuration values to edit. The command does not provide an operation for changing a socket's binding or connection.

Do not infer that a bound socket is accepting traffic, or that a connected socket is exchanging useful application data. tipc socket list reports socket and port information only. Check the owning application's logs and health checks separately.

4. Diagnose a missing TIPC interface

On a host without the TIPC kernel support or netlink family available, the command fails before it can list sockets. On this machine, the installed tool reports:

$ tipc socket list
Unable to get TIPC nl family id (module loaded?)
$ printf 'exit status: %s\n' "$?"
exit status: 1

The wording may vary by kernel and iproute2 build. The important signals are the non-zero status and the reference to the TIPC netlink family. This is not the same as a successful empty list.

Check the kernel's module inventory without changing it:

$ grep '^tipc ' /proc/modules
$ test -r /sys/module/tipc && printf '%s\n' 'TIPC module is present' || printf '%s\n' 'TIPC module is not present'

An empty module check does not by itself prove that every TIPC implementation detail is absent: support may be built into the kernel rather than loaded as a module. Ask your distribution or kernel owner how TIPC is enabled before taking action.

Privilege boundary: listing sockets is a read operation. Loading a kernel module or changing kernel networking policy is an elevated, service-impacting action and is outside this guide. If TIPC is required, schedule that change, record a rollback plan, and confirm which applications depend on it before using modprobe or changing boot configuration.

5. Use help when the installed syntax differs

The option -h or --help can be placed anywhere in the command chain. It asks for help about the last valid command, so the level you choose controls the scope:

$ tipc --help
$ tipc socket --help
$ tipc socket list --help

The first command requests general tipc help. The second requests socket help. The third requests help for the list operation if that subcommand exposes its own help text. This is useful after a distribution update, because the installed command and its local manual page are the source of truth for that host.

The top-level tipc(8) manual also documents -j and -p for JSON output and readable indentation. Do not assume that a version accepts those switches at every subcommand position: ask the installed command for help and test the exact form in a non-production shell before putting it in a parser.

6. Put the check in a script

For automation, check the exit status rather than matching a human-readable error or assuming that no rows means failure:

if tipc socket list >/tmp/tipc-sockets.$$ 2>/tmp/tipc-sockets.err.$$; then
    printf '%s\n' 'TIPC socket query succeeded'
    cat /tmp/tipc-sockets.$$
else
    status=$?
    printf 'TIPC socket query failed with status %s\n' "$status" >&2
    cat /tmp/tipc-sockets.err.$$ >&2
    rm -f /tmp/tipc-sockets.$$ /tmp/tipc-sockets.err.$$
    exit "$status"
fi
rm -f /tmp/tipc-sockets.$$ /tmp/tipc-sockets.err.$$

This example uses temporary files and removes them on the normal and error paths. If you adapt it for a long-running service, use a private temporary directory or a shell facility such as mktemp so another user cannot race the predictable names. Never parse an error message as if it were a socket row.