Remove an Offline TIPC Peer Safely with tipc

Get the address wrong and tipc peer remove can cut a live node out of your TIPC cluster instead of tidying up a dead one. This command removes one stale peer record from the local TIPC data structures, and only after you have confirmed that peer is offline. It is narrow by design: it does not configure a peer, repair a link or remove a running node from the network.

The examples below match tipc-peer(8) from iproute2 6.1.0-1ubuntu6.4, installed on this system. Allow about ten minutes if you already have the correct TIPC address, or longer if you first need to establish that the node is offline.

You need:

• a shell on the Linux host that owns the stale peer record;
• the exact TIPC peer address, supplied by your existing TIPC monitoring or operations process;
• permission to change the host's TIPC state.

Warning: This is a state-changing command. Do not paste a guessed address. The local manpage documents removal of an offline peer only, and it does not document an undo command.

1. Confirm the installed command

Check the executable and package version before using an example copied from another host. These are ordinary, read-only commands:

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

The package version matters because command help and supported operations belong to the installed iproute2 build. The relevant command shape in this build is:

tipc peer remove address ADDRESS

The ADDRESS word is a placeholder, not a value you should invent. Keep the address in the syntax used by your TIPC deployment and copy it exactly from a trusted, current inventory.

2. Establish that the peer is offline

Before changing anything, check the peer in the tool or operational record that your TIPC deployment uses. The tipc-peer(8) page does not define a peer-listing command or an address-discovery procedure, so this guide does not invent one.

Record the exact value separately from the command you are about to run:

$ PEER_ADDRESS='REPLACE_WITH_CONFIRMED_OFFLINE_ADDRESS'
$ printf 'peer selected: %s\n' "$PEER_ADDRESS"
peer selected: REPLACE_WITH_CONFIRMED_OFFLINE_ADDRESS

Checkpoint: stop if the peer is connected, its state is unknown, or the address came from an old incident note. The documented operation is specifically for an offline peer node. Removing a live or incorrectly identified node can disrupt TIPC users on this host.

3. Review the final command

Print the command with shell quoting before executing it. This catches an empty variable and makes the target visible in a terminal transcript:

$ test -n "$PEER_ADDRESS" && printf 'tipc peer remove address %q\n' "$PEER_ADDRESS"
tipc peer remove address REPLACE_WITH_CONFIRMED_OFFLINE_ADDRESS

The test only checks that the variable is non-empty. It does not prove that the address is valid or that the node is offline. Compare the printed value with your current TIPC record before continuing.

4. Remove the stale local peer record

Run the command after the checkpoint. Start without sudo; the manpage does not state a privilege requirement. If the kernel rejects the operation for lack of permission, stop and confirm the change with the host administrator before retrying with the minimum required privilege.

$ tipc peer remove address "$PEER_ADDRESS"
$ status=$?
$ printf 'exit status: %s\n' "$status"
exit status: 0

A status of zero is the documented success result. The command normally has no success text to parse, so use the exit status rather than waiting for a particular message. A positive status means failure; keep the error text and investigate the address, peer state, TIPC availability and permissions before trying again.

This changes local TIPC data structures. There is no undo or rollback command described by tipc-peer(8). If you selected the wrong peer, do not remove another record to compensate. Re-establish the correct peer state through your normal TIPC administration process, and keep the original command output for diagnosis.

5. Verify the result without guessing output

Repeat the same trusted inventory check you used in step 2. The removed offline peer should no longer be reported by that source. Exact output is deployment-specific, so do not treat an empty command response from tipc as proof by itself.

$ printf 'recheck this address in your TIPC inventory: %s\n' "$PEER_ADDRESS"
recheck this address in your TIPC inventory: REPLACE_WITH_CONFIRMED_OFFLINE_ADDRESS

If the peer reappears, first determine whether TIPC has discovered it again or whether the inventory is reading a different source. Do not repeat the removal blindly. If the command failed, preserve its non-zero status and diagnostic, then check that the address was copied exactly and that the local TIPC subsystem is available.

6. Use help when the syntax is unclear

The global help option may be placed anywhere in the command chain. Ask for help without changing peer state:

$ tipc peer --help

On a host without the TIPC netlink family available, even this query may report that it cannot obtain the TIPC family identifier. That is an environment problem, not evidence that a peer was removed. Do not respond by guessing a different address or adding unrelated options.

Done means

• Command confirmed: the installed iproute2 version and command path were checked.
• Address trusted: the target address came from a current, trusted TIPC source.
• Offline confirmed: the peer was confirmed offline before the state-changing command ran.
• Removal succeeded: tipc peer remove address ADDRESS returned exit status 0.
• Result verified: the same trusted source was checked again after removal.
• Output kept: you kept the command output because the manpage documents no undo operation.