2

I ended up in situation with a TCP port in listen mode with no process assigned to it.

Is there a way to close this port without restarting server?

Checking port status:

me> netstat -tan | grep 8888
tcp        0      0 :::8888                :::*                    LISTEN

Looking for process responsible:

me> lsof -i -P | grep 8888

Above command returns nothing

2
  • service networking restart ? Jul 15, 2011 at 16:34
  • Do you have zombie procs open? You seem to know which process opened the port. Maybe you should run ps -ef to grep for the process in question, then kill its parent PID.
    – Jodie C
    Jul 16, 2011 at 15:26

5 Answers 5

2

Try netstat -ltpn | grep 8888

10
  • 4
    also look at rpcinfo -p
    – Jodie C
    Jul 15, 2011 at 17:02
  • _______ Also not
    – poige
    Jul 15, 2011 at 17:09
  • As well what do you mean?
    – Jodie C
    Jul 15, 2011 at 20:25
  • I meant that netstat is enough to answer to original question.
    – poige
    Jul 16, 2011 at 2:54
  • 1
    @Jodie C, I've installed NFS utils, and I should admit you were right — I see [nfsd] running in kernel mode, and there're several TCP ports w/o indicated owner in netstat's output. So, you were right, rpcinfo -p is worth noting as well. Thanks :-)
    – poige
    Jul 16, 2011 at 14:46
0

run a

fuser 8888/tcp

That should list pids running on the port.

1
0

You are describing an impossible scenario.

I believe what the previous posters are missing is the fact that you are trying to map a port to a process which you do not own. Therefore your lsof returns nothing since those tools do not have permission view the /proc entries that would facilitate that port -> PID mapping. Your netstat command is lacking a -p flag as well. Run those commands as root then things will be much clearer.

2
  • I am the owner of the process. Do I need to be the root to find my own process? Jul 16, 2011 at 9:55
  • You do not need to be root to see your own processes. You can prove my theory wrong by running sudo netstat -antp | grep 8888 and posting the output. Then we can stop guessing at what the problem is. Jul 16, 2011 at 11:26
0

netstat does parse /proc/net/[tcp|udp|tcp6|udp6] and then scans the /proc/$pid/-area to find matching processes, while fuser and lsof do "only" travel through the whole /proc/$pid/-area to find which processes are known for which sockets. Ultimately, those two different approaches may end in different results.

If there is no process assigned to the socket, there are two options:

  • You're using lsof/fuser and there is no process allocating this socket, but e.g. a kernel module is doing so. You need to find that module.
  • you're running netstat as an user who may not access /proc/$pid/fd/.

For example, mounting a share via NFS does result in similar "listening" ports. So those ports will re-appear by mounting a NFS share and will disappear after unmounting the NFS share.

0

This page recommends running sudo lsof -i tcp:8888 if netstat is just a dash for the process name.

In my case it ended up being owned by a zombie process, weird, I know.

$ sudo lsof -i tcp:8888
COMMAND       PID USER FD   TYPE  DEVICE SIZE/OFF NODE NAME
my-proc-name 38116 root   16u  IPv6 326070554      0t0  TCP *:8888 (LISTEN)

Then you can look in a "ps" output for 38116 (in this case) to see the defunct process.

ps -ef grep 38116
root     38116     1  0 Apr24 ?        00:06:58 [my-proc-name] <defunct>

(my guess is it's some kind of zombie process that hasn't cleaned up yet?).

Another option:

sudo ss -apn | grep 8888

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .