Hi,
My program runs in trouble with a netstat output like bellow. It cannot receive a packet. What does the Recv-Q value in the first line mean? I see the man page, and do some googling, but no result found.

```
[root@(none) /data]# netstat -ntap | grep 8000
tcp      129      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      1526/XXXXX-
tcp        0      0 9.11.6.36:8000          9.11.6.37:48306         SYN_RECV    -
tcp        0      0 9.11.6.36:8000          9.11.6.34:44936         SYN_RECV    -
tcp      365      0 9.11.6.36:8000          9.11.6.37:58446         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:55018         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:42830         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:56344         CLOSE_WAIT  -
tcp        0    364 9.11.6.34:38947         9.11.6.36:8000          FIN_WAIT1   -
tcp      364      0 9.11.6.36:8000          9.11.6.37:52406         CLOSE_WAIT  -
tcp      365      0 9.11.6.36:8000          9.11.6.37:53603         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:47522         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.34:48191         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:51813         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.34:57789         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.37:34252         CLOSE_WAIT  -
tcp      364      0 9.11.6.36:8000          9.11.6.34:38930         CLOSE_WAIT  -
tcp      365      0 9.11.6.36:8000          9.11.6.37:44121         CLOSE_WAIT  -
tcp      365      0 9.11.6.36:8000          9.11.6.37:60465         CLOSE_WAIT  -
tcp      365      0 9.11.6.36:8000          9.11.6.37:37461         CLOSE_WAIT  -
tcp        0    362 9.11.6.34:35954         9.11.6.36:8000          FIN_WAIT1   -
tcp      364      0 9.11.6.36:8000          9.11.6.37:55241         CLOSE_WAIT  -
```

On Thu, 2016-08-25, Xiaofeng Wang wrote:
> Hi, My program runs in trouble with a netstat output like bellow. It
> cannot receive a packet. What does the Recv-Q value in the first
> line mean?
>  I see the man page, and do some googling, but no result
> found.
>
> ```
> [root@(none) /data]# netstat -ntap | grep 8000
> tcp   129   0 0.0.0.0:8000      0.0.0.0:*     LISTEN      1526/XXXXX-

The IP stack has read 129 bytes ok from the peer; they are all
accounted for and ready for the application ... except the application
hasn't read it from the IP stack yet.

It's often a sign that the application cannot keep up with the load --
or that it has gotten stuck, doing something else when it should
instead act upon the data from the peer.

But now I see it's on a LISTEN socket.  I'm not sure what a Recv-Q
there means, but I suspect it means some new clients are trying to
connect, but the server hasn't called accept(2) yet.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> But now I see it's on a LISTEN socket.  I'm not sure what a Recv-Q
> there means, but I suspect it means some new clients are trying to
> connect, but the server hasn't called accept(2) yet.

I believe you are correct, but it may depend on how new the
kernel/netstat happens to be.

rick jones
-- 
Don't anthropomorphize computers.  They hate that.  - Anonymous
these opinions are mine, all mine; HPE might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hpe.com but NOT BOTH...

> > But now I see it's on a LISTEN socket.  I'm not sure what a Recv-Q
> > there means, but I suspect it means some new clients are trying to
> > connect, but the server hasn't called accept(2) yet.
> 
> I believe you are correct, but it may depend on how new the
> kernel/netstat happens to be.

Sorry, but that's not the situation. I copy&paste a TCP example, see
https://gist.github.com/was4444/e0ed6b852dc45588e5ba5e31fb724459#file-tcp_server-c-L42, I do not accept a connection, the netstat output like bellow:

$ netstat -ntap |grep 8888
(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:8888                0.0.0.0:*                   LISTEN      20013/./server      
tcp        0      0 127.0.0.1:55566             127.0.0.1:8888              ESTABLISHED 20034/./client      
tcp       24      0 127.0.0.1:8888              127.0.0.1:55566             ESTABLISHED -  

On Friday, August 26, 2016 at 9:02:50 AM UTC+8, Xiaofeng Wang wrote:
> > > But now I see it's on a LISTEN socket.  I'm not sure what a Recv-Q
> > > there means, but I suspect it means some new clients are trying to
> > > connect, but the server hasn't called accept(2) yet.
> > 
> > I believe you are correct, but it may depend on how new the
> > kernel/netstat happens to be.
> 
> Sorry, but that's not the situation. I copy&paste a TCP example, see
> https://gist.github.com/was4444/e0ed6b852dc45588e5ba5e31fb724459#file-tcp_server-c-L42, I do not accept a connection, the netstat output like bellow:
> 
> $ netstat -ntap |grep 8888
> (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:8888                0.0.0.0:*                   LISTEN      20013/./server      
> tcp        0      0 127.0.0.1:55566             127.0.0.1:8888              ESTABLISHED 20034/./client      
> tcp       24      0 127.0.0.1:8888              127.0.0.1:55566             ESTABLISHED -

not true with kernel version 2.6
$ uname -r
2.6.32-642.3.1.el6.x86_64

but with kernel version 3.10, it is true.

On Friday, August 26, 2016 at 9:14:39 AM UTC+8, Xiaofeng Wang wrote:
> On Friday, August 26, 2016 at 9:02:50 AM UTC+8, Xiaofeng Wang wrote:
> > > > But now I see it's on a LISTEN socket.  I'm not sure what a Recv-Q
> > > > there means, but I suspect it means some new clients are trying to
> > > > connect, but the server hasn't called accept(2) yet.
> > > 
> > > I believe you are correct, but it may depend on how new the
> > > kernel/netstat happens to be.
> > 
> > Sorry, but that's not the situation. I copy&paste a TCP example, see
> > https://gist.github.com/was4444/e0ed6b852dc45588e5ba5e31fb724459#file-tcp_server-c-L42, I do not accept a connection, the netstat output like bellow:
> > 
> > $ netstat -ntap |grep 8888
> > (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:8888                0.0.0.0:*                   LISTEN      20013/./server      
> > tcp        0      0 127.0.0.1:55566             127.0.0.1:8888              ESTABLISHED 20034/./client      
> > tcp       24      0 127.0.0.1:8888              127.0.0.1:55566             ESTABLISHED -
> 
> not true with kernel version 2.6
> $ uname -r
> 2.6.32-642.3.1.el6.x86_64
> 
> but with kernel version 3.10, it is true.

The Recv-Q in a LISTEN state means the count of un-accepted connections in kernel version 3.10

> > [root@(none) /data]# netstat -ntap | grep 8000
> > tcp   129   0 0.0.0.0:8000      0.0.0.0:*     LISTEN      1526/XXXXX-

the default listen's backlog is 128 according the man page:
http://linux.die.net/man/2/listen
and the value of /proc/sys/net/core/somaxconn is truly 128.