Red Hat Bugzilla – Bug 614931
netstat -a does not report non listening sockets
Last modified: 2011-05-19 10:03:14 EDT
Description of problem:
Reading netstat manpage:
Show both listening and non-listening sockets. With the --interfaces option, show interfaces that are not marked
But using portreserve to claim some tcp port, it does not show in the list.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum install net-tools portreserve
2. echo 12345 > /etc/portreserve/test
3. service portreserve start
4. netstat -n -a | grep 12345
udp 0 0 0.0.0.0:12345 0.0.0.0:*
tcp 0 0 0.0.0.0:12345 0.0.0.0:*
udp 0 0 0.0.0.0:12345 0.0.0.0:*
CCing twaugh - from what he says, portreserve really binds the port, just does not listen to it, and how do I understand the docs, the "-a" option should ensure that it gets listed anyways.
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
ss command shows the same.
# ss -u -a -n | grep 12345
UNCONN 0 0 *:12345 *:*
# ss -t -a -n | grep 12345
man 8 ss
ss is used to dump socket statistics. It allows showing information similar to netstat. It can display more TCP and state informations than other tools.
Do now try to resolve service names.
Display all sockets.
Display only TCP sockets.
Display only UDP sockets.
(In reply to comment #0)
> Steps to Reproduce:
> 1. yum install net-tools portreserve
> 2. echo 12345 > /etc/portreserve/test
> 3. service portreserve start
> 4. netstat -n -a | grep 12345
netstat uses /proc/net/* to get the informations about active sockets.
12345 is 3039 in hexadecimal., When we try to
'grep 3039 /proc/net/*' we find 00000000:3039 only in /proc/net/udp.
> portreserve really binds the port, just does not listen to it
When you create TCP connection you
either call bind()+listen() in case of server
or connect() in case of client.
When you have TCP socket and call bind() but not listen()
then it's not a valid (it's neither listening server nor established connection)
TCP connection and therefore it's not in /proc/net/tcp
and netstat doesn't show it.
It's in /proc/net/udp because there's no need to call listen() on UDP socket.
> and how do I understand the docs, the "-a" option should ensure that it gets listed anyways.
Yes but only if it's valid "server" or "established" (I use the netstat terminology).
# netstat | grep Active
Active Internet connections (w/o servers)
Active UNIX domain sockets (w/o servers)
# netstat -l | grep Active
Active Internet connections (only servers)
Active UNIX domain sockets (only servers)
# netstat -a | grep Active
Active Internet connections (servers and established)
Active UNIX domain sockets (servers and established)
Maybe we could improve the '-a' option documentation in man page.
- Show both listening and non-listening sockets.
+ Show both listening and non-listening (for TCP this means established connections) sockets.
(Your english is definitely better then my so if you have other idea how to improve the documentation, it's welcomed).
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Prior to this update, the manual page for the netstat utility stated that running the utility with the "-a" (or "--all") command line option allows a user to list both listening and non-listening sockets. Since this description was rather vague, this update extends the manual page to provide a clear explanation of which sockets are classified as non-listening.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.