45

I have a process which listen to 2 ports : 45136/tcp and 37208/udp (actually I assume it is the same process). But netstat doesn't return any pid :

netstat -antlp | grep 45136
tcp        0      0 0.0.0.0:45136           0.0.0.0:*           LISTEN      - 

Same result with "grep 37208".

I tried lsof too :

lsof -i TCP:45136

But it doesn't return anything. It's a new installation of squeeze and I really don't know what could be this process. Any idea ?

ANSWER Thanks to your comments I found out what it was. I deinstalled nfs-server nfs-common (after a dkpg --get-selections | grep nfs search) and the unknown process disapeared. Strange though that kernel processes aren't marked in any way.

Thanks again to both of you. ;)

55

netstat

There's a process there, your userid just isn't privy to seeing what it is. This is a layer of protection provided by lsof that's keeping you from seeing this. Simply re-run the command but prefix it using the sudo command instead.

$ sudo netstat -antlp | grep 45136

There's even a warning about this in the output of lsof at the top.

(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)

Example

$ netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      -                   

$ sudo netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      1248/rpcbind

ss

If you're not having any luck with netstat perhaps ss will do. You'll still need to use sudo, and the output can be a little bit more cryptic.

Example

$ ss -apn|grep :111
LISTEN     0      128         :::111             :::*     
LISTEN     0      128          *:111              *:*     

$ sudo ss -apn|grep :111
LISTEN     0      128         :::111             :::*      users:(("rpcbind",1248,11))
LISTEN     0      128          *:111              *:*      users:(("rpcbind",1248,8))

Process ID still not there?

There are instances where there simply isn't a PID associated to the TCP port in use. You can read about NFS, in @derobert's answer, which is one of them. There are others. I have instances where I'm using ssh tunnels to connect back to services such as IMAP. These are showing up without a process ID too.

In any case you can use a more verbose form of netstat which might shed additional light on what process is ultimately using a TCP port.

$ netstat --program --numeric-hosts --numeric-ports --extend

Example

$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address               Foreign Address             State       User       Inode      PID/Program name   
tcp        0      0 192.168.1.103:936           192.168.1.3:60526           ESTABLISHED root       160024310  -                   
tcp        0      0 192.168.1.1:2049            192.168.1.3:841             ESTABLISHED sam        159941218  -                   
tcp        0      0 127.0.0.1:143               127.0.0.1:57443             ESTABLISHED dovecot    152567794  13093/imap-login    
tcp        0      0 192.168.1.103:739           192.168.1.3:2049            ESTABLISHED root       160023970  -                   
tcp        0      0 192.168.1.103:34013         192.168.1.3:111             TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:46110             127.0.0.1:783               TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.102:54891         107.14.166.17:110           TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:25                127.0.0.1:36565             TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.1:2049            192.168.1.6:798             ESTABLISHED tammy      152555007  -             

If you notice the output includes INODES so we could back track into the process using this info.

$ find -inum 152555007

Which will show you a file which might lead you to a process.

References

  • @derobert - I was thinking they were threads. – slm Oct 27 '13 at 4:04
  • @slm (userspace) threads have PIDs. – derobert Oct 27 '13 at 4:05
  • @derobert - that's what I thought but was double checking to be sure. – slm Oct 27 '13 at 4:05
  • @derobert - I found this: "The Linux kernel itself provides the NFS server (aka "knfsd"). Thus there is no associated process because the kernel is not a process." – slm Oct 27 '13 at 4:10
  • @JohnDoe - it might be that they're related to NFS. – slm Oct 27 '13 at 4:12
16

Another option is that the socket doesn't belong to a process, it belongs to the kernel. One common example of this is NFS.

Watt:~# netstat -ltp | egrep -- '-[[:space:]]*$'
tcp        0      0 *:nfs                   *:*                     LISTEN      -               
tcp        0      0 *:48131                 *:*                     LISTEN      -               
tcp6       0      0 [::]:55607              [::]:*                  LISTEN      -               
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN      -               

I'm not sure a good way, in general, to identify these. In the particular case of NFS, rpcinfo will often be able to tell us:

anthony@Watt:~$ rpcinfo -p | grep 48131
    100021    1   tcp  48131  nlockmgr
    100021    3   tcp  48131  nlockmgr
    100021    4   tcp  48131  nlockmgr

Unfortunately, that only works for IPv4. To get v6, you have to leave off -p, which then displays port numbers in a silly manner: As two additional octets of IP address. Port 55607 thus becomes 217.55 (because 217 × 256 + 55 = 55607):

anthony@Watt:~$ rpcinfo  | grep -i 217.55
    100021    1    tcp6      ::.217.55              nlockmgr   superuser
    100021    3    tcp6      ::.217.55              nlockmgr   superuser
    100021    4    tcp6      ::.217.55              nlockmgr   superuser
  • 1
    Thank you for pointing out rpcinfo -p only works for IPv4 – youfu Jul 9 '17 at 4:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.