Linux netstat no pid

How to parse netstat command in order to get process name and PID from it?

I need to get in result only name of the process and PID, i.e java 3591. What is best way to do it? Thank you.

8 Answers 8

ps -p $(lsof -ti tcp:80) o comm=,pid= 

Second one worked in Ubuntu 13.10 but I needed to sudo . I modified it a bit: sudo netstat -tlnp | awk ‘/:80 */ ‘ | xargs ps x -p

This does not seem to work? echo «tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1080/nginx: master» | awk ‘/:80 */ ‘ returns master .

@ChrisStryczynski: The output of netstat includes more than one space between columns for me, so adding a multispace delimiter to the AWK command seems to work: netstat -tlnp | awk -F ‘ ‘ ‘/:80 */ ‘ (that’s two spaces in the argument of -F )

(Detracting slightly from your original question), to find out which process listens to a certain port number, I usually use the lsof command. For example:

To show only the process name and PID, parse the output using:

The tail command skips the output header while awk prints out the required columns.

Why lsof

Trying to grep the output of netstat can be messy as you’ll need to make sure you’re matching against the correct column. A robust solution can be rather long winded and difficult (for me anyway) to produce on-demand.

lsof saves you the trouble of matching the right ports, and has lots of other uses too, e.g. the inverse of what we’re doing now (find out which ports are being used by a process), or determining which process is using a file / mount point (or the inverse). See lsof manpage for more examples.

Источник

How to identify a process which has no pid?

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 - 

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. 😉

2 Answers 2

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.

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

Источник

netstat -ntap doesn’t show pid/process name for some connections?

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.

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.

5 Answers 5

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

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) 

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.

These are definitely not kernel based connections as these are connections to database from application.

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 -«

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)

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.

Источник

netstat shows a listening port with no pid but lsof does not

From data you provided I’d say it’s related to some NFS mounts or something using RPC.

you can check with rpcinfo -p for ports that might be used by some of RPC related services.

Here is how it looks on my system

# netstat -nlp | awk '' tcp 0 0 0.0.0.0:55349 0.0.0.0:* LISTEN - udp 0 0 0.0.0.0:18049 0.0.0.0:* - # rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10249 status 100024 1 tcp 10249 status 100021 1 udp 18049 nlockmgr 100021 3 udp 18049 nlockmgr 100021 4 udp 18049 nlockmgr 100021 1 tcp 55349 nlockmgr 100021 3 tcp 55349 nlockmgr 100021 4 tcp 55349 nlockmgr 

Solution 3:

Based on hint from @user202173 and others I have been able to use the following to track down the process that owns a port even when it is listed as — in netstat.

Here was my starting situation. sudo netstat shows port with PID/Program of — . lsof -i shows nothing.

$ sudo netstat -ltpna | awk 'NR==2 || /:8785/' Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 . 8785 . * LISTEN - tcp6 1 0 ::1:8785 ::1:45518 CLOSE_WAIT - $ sudo lsof -i :8785 $ 

Now let’s go fishing. First let’s get the inode by adding -e to our netstat call.

$ sudo netstat -ltpnae | awk 'NR==2 || /:8785/' Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp6 0 0 . 8785 . * LISTEN 199179 212698803 - tcp6 1 0 ::1:8785 ::1:45518 CLOSE_WAIT 0 0 - 

Next use lsof to get the process attached to that inode.

$ sudo lsof | awk 'NR==1 || /212698803/' COMMAND PID TID USER FD TYPE DEVICE SIZE/OFF NODE NAME envelope_ 145661 145766 drees 15u IPv6 212698803 0t0 TCP *:8785 (LISTEN) 

Now we know the process id so we can look at the process. And unfortunately it’s a defunct process. And its PPID is 1 so we can’t kill its parent either (see How can I kill a process whose parent is init?). In theory init might eventually clean it up, but I got tired of waiting and rebooted.

$ ps -lf -p 145661 F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 Z drees 145661 1 2 80 0 - 0 exit May01 ? 00:40:10 [envelope]

Solution 4:

I don’t know what these are specifically, but kernel modules (NFS for example) do not have a PID to associate with these sockets. Look for something suspect in lsmod.

Solution 5:

I dont know if this can be useful. I had the same problem and what I did is the following: First, I called netstat with options -a(all) and -e(extended). With the latter option I can see the Inode associated to the used port. Then, I called lsof |grep with the inode number obtained and I got the PID of process associated to that inode. That worked in my case.

Источник

linux + port in use + but no PID return from netstat to kill the PID

we have Hadoop cluster — the linux are rhel 7.5 machines and namenode is using the port 50070 we can see from the log that port 50070 is in use but the interesting thing is that when we do netstat -tulpn | grep 50070 , to find the PID , the its return nothing

netstat -tulpn | grep 50070 ( we not get output ) 

2020-07-18 21:26:22,753 INFO impl.MetricsSystemImpl (MetricsSystemImpl.java:shutdown(606)) - NameNode metrics system shutdown complete. 2020-07-18 21:26:22,753 ERROR namenode.NameNode (NameNode.java:main(1783)) - Failed to start namenode. java.net.BindException: Port in use: linux.gg.com:50070 at org.apache.hadoop.http.HttpServer2.constructBindException(HttpServer2.java:1001) at org.apache.hadoop.http.HttpServer2.bindForSinglePort(HttpServer2.java:1023) at org.apache.hadoop.http.HttpServer2.openListeners(HttpServer2.java:1080) at org.apache.hadoop.http.HttpServer2.start(HttpServer2.java:937) at org.apache.hadoop.hdfs.server.namenode.NameNodeHttpServer.start(NameNodeHttpServer.java:170) at org.apache.hadoop.hdfs.server.namenode.NameNode.startHttpServer(NameNode.java:942) at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:755) at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:1001) at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:985) at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1710) at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1778) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:433) at sun.nio.ch.Net.bind(Net.java:425) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:216) at org.apache.hadoop.http.HttpServer2.bindListener(HttpServer2.java:988) at org.apache.hadoop.http.HttpServer2.bindForSinglePort(HttpServer2.java:1019) . 9 more 2020-07-18 21:26:22,755 INFO util.ExitUtil (ExitUtil.java:terminate(124)) - Exiting with status 1 2020-07-18 21:26:22,757 INFO namenode.NameNode (LogAdapter.java:info(47)) - SHUTDOWN_MSG: /************************************************************ SHUTDOWN_MSG: Shutting down NameNode at ************************************************************/ [root@linux hdfs]# [root@linux hdfs]# [root@linux hdfs]# netstat -tulpn | grep 50070 ( no PID number is returned ) 

Источник