1

When I use ss (socket statistics) to show the usages of port 5432 I get:

$ sudo ss -ln | grep -E 'State|5432' Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess u_str LISTEN 0 244 /var/run/postgresql/.s.PGSQL.5432 54481 * 0 tcp LISTEN 0 244 127.0.0.1:5432 0.0.0.0:*

When using lsof (list of open files) instead I get no result:

$ sudo lsof -i tcp:5432

Why is that?

Related to:

Edit with answers from comments:

  • sudo ss -lnp does not show the pid of the process(es) that have that listening socket
  • the 127.0.0.1:5432 0.0.0.0:* on the last line was a copy-paste error, sorry about that, I have removed it
  • I am running those commands in a WSL terminal, Postgres is not running anywhere

Edit with new findings:

I have found out this is happening only when Docker Desktop is running (even though there is no container running): ss doesn't output anything once I quit Docker Desktop. It looks like this might be an issue somehow related with Docker Desktop: I have reported it in this GitHub issue.

Improve this question
11
  • 1
    Does sudo ss -lnp show the pid of the process(es) that have that listening socket? Commented Jun 8, 2024 at 10:05
  • 1
    Is the repeated 127.0.0.1:5432 0.0.0.0:* on the last line a copy-paste error or actual part of ss output? Commented Jun 8, 2024 at 10:09
  • 1
    Are you running those commands or is postgresql running in some form of container or other form of separate network/mount/process namespace? Commented Jun 8, 2024 at 10:11
  • 1
    One difference is that lsof needs /proc, while ss doesn't unless you use -p. Commented Jun 8, 2024 at 13:41
  • 1
    I take solace in the fact that lsof's documentation is wrong (at least on Linux), and it doesn't need to access /dev/[k]mem to do its thing, but simply walks /proc/*/fd and talks to netlink to get network info. But seriously, no good reason to use lsof to monitor TCP ports: a quick strace lsof -i tcp:1234 tells us that lsof still walks all /proc/*/fd/* (that's over 10000 on my machine right now), although it needs none of that. Simply don't use lsof for a job it's not meant to do. Commented Jun 8, 2024 at 13:52

1 Answer 1

Reset to default
0

It turned out it was after all a problem on my machine. I had another instance of WSL running side to side that I forgot of and that one had a Postgres server running and listening to that port. I wrongly assumed they were running in isolation from each other while instead they are not. Uninstalling Postgres from that WSL instance fixed my issue.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.