ss -o: show TCP timers (retransmit, keepalive, timewait) per connection
- tool
- ss / netstat
- command
- ss
- flag
- -o, --options
- default
- off (no timer information)
ss -o adds a timer:(NAME,EXPIRES,RETRANS) field to TCP sockets: which kernel timer is running on the connection, how long until it fires, and how many retransmissions have happened. It is the quickest way to see whether TCP keepalive is active on long-lived connections (database pools, message brokers, SSH tunnels), whether a connection is stuck retransmitting, or how long sockets stay in TIME-WAIT. Without -o, ss prints addresses, ports, states and queues only.
Typical commands
ss -tno state established # established connections with their timers
ss -tno state established '( dport = :5432 )' # only connections to PostgreSQL
ss -tno state time-wait | head # sockets in TIME-WAIT and their remaining time
ss -tnoi dst 192.0.2.10 # timers plus rtt and retransmit detailsTimer names
The ss manual lists five timer names:
| Timer | Meaning |
|---|---|
| on | Retransmission timer, early retransmit or tail loss probe: unacknowledged data is outstanding |
| keepalive | TCP keepalive timer: the socket has SO_KEEPALIVE set and will probe the idle peer |
| timewait | TIME-WAIT state timer after the connection was closed |
| persist | Zero window probe timer: the peer advertised a zero receive window |
| unknown | None of the above |
EXPIRES is the time left until the timer fires, and RETRANS is the number of retransmissions so far. An idle established connection without keepalive usually shows no timer at all.
What the timers tell you
- Keepalive missing: connections through NAT gateways and load balancers that drop idle flows are silently cut. If
timer:(keepalive,...)is absent, enable keepalive in the application or driver (for example thekeepalivesandkeepalives_idleparameters of libpq connection strings); the kernel defaults are in/proc/sys/net/ipv4/tcp_keepalive_timeand the related settings described in tcp(7). onwith rising retransmissions: the peer is not acknowledging data. Check the path withss -ti(rtt,retrans), see ss TCP info: rtt and retransmits.persist: the receiver's buffer is full; the problem is on the reading side, not the network.- Large numbers of
timewait: normal for clients that open many short connections; count them by state with ss count connections by state.
Related options
| Option | Adds |
|---|---|
| -o, --options | Timer name, expiry and retransmissions |
| -i, --info | rtt, cwnd, mss, retrans and more TCP internals |
| -e, --extended | uid, inode and socket cookie |
| -p, --processes | The owning process (see ss -p) |
| -n, --numeric | Numeric ports and addresses |
State names used in filters such as state established and state time-wait are listed in TCP socket states; to see which program owns a connection add -p.
FAQ
How do I check that TCP keepalive is enabled on a connection?
Run ss -tno state established and look for timer:(keepalive,...). Only sockets whose application set SO_KEEPALIVE have that timer; connections without it show no timer field or another timer.
What does a growing retrans count in timer:(on,...) mean?
The kernel is retransmitting unacknowledged data on that connection. A count that keeps increasing points to packet loss or a peer that stopped answering; ss -ti shows the retransmission totals and rtt.
Why do I see many timer:(timewait,...) entries?
Each recently closed connection stays in TIME-WAIT for about a minute on Linux so late packets are not misinterpreted. Many of them are normal on busy clients and proxies.