Linux – TCP monitoring on a server: comparing netstat vs lsof

linuxlsofnetstattcpunix

I'm monitoring the TCP stack on a server hoping to generically infer problems with application on the box.

My first inclination is to measure the number of sockets in all reported states (LISTEN,ESTABLISHED,FIN_WAIT2,TIME_WAIT, etc) and detect some anomalies.

A teammate suggests that 'lsof' would be a better tool to see what state the TCP stacks are in.

Any preferences or experience tips from the serverfault crowd?

Best Answer

I prefer lsof because it's output is consistent across all platforms on which it runs. You can pretty much get the same info from both programs, though. I think it comes down to personal preference.

Related Solutions

Lsof not showing what port a proc is listening on

You'd rather use pfiles which is part of Solaris and supported by Sun, unlike lsof.

Its usage is slightly different as it expects a pid as argument but you can achieve what you want with something like:

pfiles $(pgrep libhttpd)

or even, if you don't know the process name:

pfiles /proc/*

Linux – Sockets found by lsof but not by netstat

This can occur if you create a socket, but never connect() or bind() with it. Your best bet may be to strace (-fF) the application, and then cross-reference with the output of lsof to determine which sockets are causing the issue. As a bonus method of debugging: if you wrap your socket calls with debugging information and write them out to /dev/null, it'll appear in strace without giving you hilariously-large log files.

Best Answer

Related Solutions

Lsof not showing what port a proc is listening on

Linux – Sockets found by lsof but not by netstat

Related Topic