How to identify a process which has no pid?
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
- Port to PID
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