22

I have ubuntu/hardy server, with kernel 2.6.24-23-server and netstat:

# netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)

The problem is that we have a lot of ESTABLISHED connections that don't show PID nor Program name in netstat -ntap output. Netstat was called from root, there are no chroots, grsecurity, nor anything like this (or so I was told :).

Any idea on what might be wrong?

UPDATE

lsof -n -i works ok, and shows pid/process name for the connections.

  • Are you sure you were not doing `netstat -ntap` instead of `netstat ntap` ? – Kyle Brandt Nov 17 '09 at 17:07
  • I am sure I was doing `netstat -ntap` - just as i wrote. as this is the way options are given to netstat according to its man page. –  Nov 17 '09 at 17:14
  • Side note - i just checked and it seems that netstat doesn't recognize options given without "-". –  Nov 17 '09 at 17:15
  • 4
    Are you sure to run it as root or with sudo ? – Dom Nov 17 '09 at 16:02
  • Yes, it was run on root, and even on root via sudo. same effect. –  Nov 17 '09 at 16:04

5 Answers5

12
198_141:~ # netstat  -anp|grep 33000
tcp        0      0 0.0.0.0:53000           0.0.0.0:*               LISTEN       -                   
198_141:~ # lsof -i:33000
COMMAND   PID USER   FD   TYPE     DEVICE SIZE NODE NAME
vsftpd  28147 root    3u  IPv4 4089990174       TCP *:33000 (LISTEN)
198_141:~ # id
uid=0(root) gid=100(users) groups=16(dialout),100(users)
198_141:~ #

in my oninion,there could be two situations:

1) normal privilege user excute "netstat" cann't see those processes launched by root

2) some processes run in kernel

Community
  • 1
Yans Ruan
  • 221
  • 2
  • 3
5

This will occur with kernel processes like NFS, but also occasionally occurs with regular apps: RHEL 5 has the same behaviour. 

# netstat -taupen | grep 30715
tcp        0      0 0.0.0.0:30715           0.0.0.0:*               LISTEN      66558      81467710   -

Note that lsof, on the other hand, words properly:

# lsof -i:30715
AppName 1598 useracct   78u     IPv4           81467710                   TCP *:30715 (LISTEN)
Nathan Williams
  • 63
  • 1
  • 6
mikemaccana
  • 3,070
  • 5
  • 24
  • 29
1

I have the same behaviour and my guess is that netstat behavior may have changed. For example I see the port and program for 'wget', but not for Apache PHP processes, which are the more important to me.

Workaround: I rewrote my script to use lsof instead (see hint above)

1

For established connections, this should only happen for connections that are initiated from kernel space, like NFS or DRBD. Obviously waiting connections could have had the process die underneath them. If you can't work out what is causing a given connection, paste the output and someone can tell you what it is.

womble
  • 95,029
  • 29
  • 173
  • 228
  • These are definitely not kernel based connections as these are connections to database from application. –  Nov 17 '09 at 16:07
  • Output of netstat -atnp |grep EST ? – womble Nov 17 '09 at 16:18
  • this is what my problem is - connections are listed by instead of pid/program name i have "-" –  Nov 17 '09 at 16:25
  • 3
    And I'd like to see what is *actually* happening, rather than an interpretation thereof. – womble Nov 17 '09 at 16:31
  • I cannot show you whole output as it contains names that could be used to identify the environment. the line for this particular port looks like this: "tcp 0 0 localhost:36949 localhost:6543 ESTABLISHED -" –  Nov 17 '09 at 17:12
1

Arrive here because these days I encounter the same question on ubuntu 18.04 LTS (netstat is the same version netstat 1.42 (2001-04-15)), strange still no answer after 8 years. After browsing the source code of net-tools, I may find it.

In the netstat source code:

  1. all process folders in /proc are iterated, each fd in /proc//fd directory is checked to build a map from socket inode to pid/progname.

  2. then /proc/net/tcp is checked to get tcp socket information(by the tcp_info function), including the socket inode.

  3. when outputting the tcp socket information , the pid/progname is queried from the map in step 1 via the socket inode. if nothing is found, '-' outputs.

If the socket is created after the map is built, the pid/progname will not be found in the map.

zenkj
  • 11
  • 3