24

I try to start the Python SimpleHTTPServer on port 7054 :

$ sudo python -m SimpleHTTPServer 7054
...
socket.error: [Errno 98] Address already in use

So, I ran the following commands :

$ sudo netstat -ntpu | grep 7054
$ sudo lsof -i -n -P | grep 7054

But I have no results.

approxiblue
  • 6,982
  • 16
  • 51
  • 59
pgmillon
  • 361
  • 1
  • 2
  • 6
  • Looks like this one, man : https://stackoverflow.com/questions/19071512/socket-error-errno-48-address-already-in-use – Louis May 28 '14 at 09:07
  • The netstat and lsof commands should display any processes using the 7054 port. But nothing pop's out. – pgmillon May 28 '14 at 09:38
  • whats with sudo why not run using root. This could be the reason. not sure though –  May 28 '14 at 10:07
  • 1
    @daa. Why would sudo not work? – Padraic Cunningham May 28 '14 at 10:15
  • I think may be the netstat not working with sudo at all. –  May 28 '14 at 10:29
  • sudo is used to elevate the account if not logged in as root. If you do not elevate the account, you may not see all ports in use. [Reference](http://knowledgebase.pearsonschool.com/kmp/article/AA-02787/0/SMAKER%3A-How-to-use-netstat-Network-Statistics.html). Again I may be wrong –  May 28 '14 at 10:32
  • 1
    Netstat not working with sudo is highly uncertain BUT I tried (just in case) to run the commands directly as root) and the (no) results is the same. No processes use the port 7054 and yet I still have an "Address already in use" error. – pgmillon May 28 '14 at 10:36
  • sudo gives you root privileges without having to login as root. – Padraic Cunningham May 28 '14 at 11:27
  • 2
    I'm debugging a server program, and if I kill it without explicitly closing the server socket, I get this error for about 30 seconds. Seems that simply waiting a bit solves it. – sudo Sep 01 '16 at 05:20

2 Answers2

13

From the netstat manpage:

netstat   [address_family_options]   [--tcp|-t]   [--udp|-u]   [--raw|-w]   [--listening|-l]  [--all|-a]  [--numeric|-n]  [--numeric-hosts]  [--numeric-ports]
[--numeric-users] [--symbolic|-N] [--extend|-e[--extend|-e]] [--timers|-o] [--program|-p] [--verbose|-v] [--continuous|-c]

I use the following options:

sudo netstat -tanl | grep 7054

Which is --numeric, --tcp, --all, --listening

I think the minimal netstat options you need to show the pid of the process listening on a particular port are -nlp.

The lsof options you specify work for me. Using the example code at https://wiki.python.org/moin/UdpCommunication#Receiving and python -m SimpleHTTPServer 7054:

$ netstat -nlp | grep 7054
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:7054            0.0.0.0:*               LISTEN      20458/python    
udp        0      0 0.0.0.0:7054          0.0.0.0:*                           20498/python    
$ lsof -i -n -P | grep 7054
python    20458 michael    3u  IPv4 143736      0t0  TCP *:7054 (LISTEN)
python    20498 michael    3u  IPv4 173739      0t0  UDP *:7054 

Extra credit: stick it in an alias:

listening() {
    netstat -nlp | grep $1
}

And use it:

$ listening 7054
approxiblue
  • 6,982
  • 16
  • 51
  • 59
michaeljoseph
  • 7,023
  • 5
  • 26
  • 27
  • Sorry but -tu is for TCP _or_ UDP not _and_ : sudo netstat -lnptu | grep 63342 tcp 0 0 127.0.0.1:63342 This process is not listening on UDP but only TCP – pgmillon Jul 19 '14 at 16:00
  • Right. So then it's the missing `--listen` option that's the problem? – michaeljoseph Jul 20 '14 at 10:24
  • did you get the solution ? – user1 Nov 15 '15 at 20:44
  • For windows users: Try `netstat -anop tcp | frindstr 7054`. It gives you the PID in the last column and with `tasklist | findstr ` you can get the process executable name for your PID to see who is allocating the port. – sinned Jul 06 '20 at 14:14
1

An address can be in use, but not shown by lsof, ss or netstat once bind has been used on a SOCK_STREAM socket, but before the named socket has been set the LISTEN state.

This was found with a test performed using AlmaLinux 8.6 with a 4.18.0-372.19.1.el8_6.x86_64 Kernel. The source for the test program is in bind_local.c

Start the test program, specifying an IPv6 link-local address and port number (10000) to bind to:

[mr_halfword@haswell-alma ibv_message_passing]$ ibv_message_passing_c_project/bin/debug/bind_local/bind_local  -6 fe80::207:43ff:fe15:2298%4 -p 10000 -l
fd 3 bound to fe80::207:43ff:fe15:2298 scope-id 4 port 10000
Press enter to listen on port

At the above port a SOCK_STREAM socket has been created, bind called and getsockname used to get the socket name which is displayed (i.e. the address the socket has been bound to).

The socket file-descriptor the test program has bound is shown as socket 398999:

[mr_halfword@haswell-alma ~]$ ls -l /proc/`pgrep bind_local`/fd
total 0
lrwx------. 1 mr_halfword mr_halfword 64 Sep 10 17:08 0 -> /dev/pts/0
lrwx------. 1 mr_halfword mr_halfword 64 Sep 10 17:08 1 -> /dev/pts/0
lrwx------. 1 mr_halfword mr_halfword 64 Sep 10 17:08 2 -> /dev/pts/0
lrwx------. 1 mr_halfword mr_halfword 64 Sep 10 17:08 3 -> 'socket:[398999]'

In this state attempting to use nc to listen on port 10000 fails with Address already in use, but neither lsof not ss show the address:

[mr_halfword@haswell-alma ~]$ nc -l 10000
Ncat: bind to :::10000: Address already in use. QUITTING.
[mr_halfword@haswell-alma ~]$ sudo lsof -i -n -P | grep 10000
[mr_halfword@haswell-alma ~]$ sudo ss -nlp | grep 10000
[mr_halfword@haswell-alma ~]$ 

Cause the test program to call listen on the bound socket, by pressing return:


Press return to exit

Now that the bound socket is in the LISTEN state attempting to use nc to listen on port 10000 fails with Address already in use, but now lsof and ss are showing the address and which program is using the address:

[mr_halfword@haswell-alma ~]$ sudo lsof -i -n -P | grep 10000
bind_loca 16929 mr_halfword    3u  IPv6 398999      0t0  TCP [fe80::207:43ff:fe15:2298]:10000 (LISTEN)
[mr_halfword@haswell-alma ~]$ sudo ss -nlp | grep 10000
tcp   LISTEN 0      1                       [fe80::207:43ff:fe15:2298]%enp1s0f4d1:10000               [::]:*     users:(("bind_local",pid=16929,fd=3))                                  

I haven't yet tried looking at the Linux Kernel source code to determine if a SOCK_STREAM socket which has been bound to an address by being named, but left in that state, has any user space method which can locate the program using the address.

The reason the above was investigating how the iwpmd iWARP Port Mapper Daemon was claiming TCP ports, for which was unable to find a way to list the claimed TCP ports.

Chester Gillon
  • 326
  • 2
  • 4
  • For a ``SOCK_DGRAM`` socket the issue doesn't apply, in that once have called ``bind`` the address is shown by ``lsof``, ``ss`` and ``netstat``. – Chester Gillon Sep 10 '22 at 17:34