linux : netstat listening queue length

Question

Is there a way to view queue length on listening socket under Linux, the same way as netstat -L outputs for FreeBSD? I.e. you can see X/Y/Z in netstat -L output, but netstat under Linux doesn't support -L flag.

Solution 1

Let's look into source code, as it's the best documentation in the world of open source.

net/ipv4/tcp_diag.c:

if (sk->sk_state == TCP_LISTEN) {
    r->idiag_rqueue = sk->sk_ack_backlog;
    r->idiag_wqueue = sk->sk_max_ack_backlog;
} else {
    r->idiag_rqueue = max_t(int, tp->rcv_nxt - tp->copied_seq, 0);
    r->idiag_wqueue = tp->write_seq - tp->snd_una;
}

The same thing we can see in unix domain sockets, net/unix/diag.c:

if (sk->sk_state == TCP_LISTEN) {
    rql.udiag_rqueue = sk->sk_receive_queue.qlen;
    rql.udiag_wqueue = sk->sk_max_ack_backlog;
} else {
    rql.udiag_rqueue = (u32) unix_inq_len(sk);
    rql.udiag_wqueue = (u32) unix_outq_len(sk);
}

So.

If socket is established, Recv-Q and Send-Q means bytes as it's described in documentation.
If socket is listening, Recv-Q means current queue size, and Send-Q means configured backlog.

Going deeper into mans gives us folowing in sock_diag(7):

      UDIAG_SHOW_RQLEN
             The attribute reported in answer to this request is
             UNIX_DIAG_RQLEN.  The payload associated with this
             attribute is represented in the following structure:

                 struct unix_diag_rqlen {
                     __u32 udiag_rqueue;
                     __u32 udiag_wqueue;
                 };

             The fields of this structure are as follows:

             udiag_rqueue
                    For listening sockets: the number of pending
                    connections.  The length of the array associated
                    with the UNIX_DIAG_ICONS response attribute is
                    equal to this value.

                    For established sockets: the amount of data in
                    incoming queue.

             udiag_wqueue
                    For listening sockets: the backlog length which
                    equals to the value passed as the second argu‐
                    ment to listen(2).

                    For established sockets: the amount of memory
                    available for sending.

In other words, ss -ln is the only command you need

Solution 2

ss -l shows the correct Recv-Q Send-Q.

Solution 3

There is no simple way to see that on Linux as far as I know. Recv-Q and Send-Q are not listen queue. They are the count of bytes not copied by the user program connected to the socket and not acknowledged by the remote host (see man netstat). So they are about established connections. Listen (accept) queue is a place where kernel keeps new incoming connections until your application calls accept().

Solution 4

awk can help:

netstat -ntp | awk '{ if ($6 == "ESTABLISHED" && $7 == "-") arrQueue[$4] += 1; } END { for (service in arrQueue) print service" "arrQueue[service] }'

Source: http://mysyslog.ru/posts/633

View more solutions

Comments

[Artem G]

Thanks for the answer. Actually ss -l shows the correct Recv-Q Send-Q, so its faster to do it not with awk.

[Pavel Timofeev]

Sorry, I wasn't completely correct. netstat and ss on new Linux distributions show different things as Recv-Q and Send-Q value depending on if it's established connection or listening socket. This is from CentOS 7.4: Recv-Q Established: The count of bytes not copied by the user program connected to this socket. Listening: Since Kernel 2.6.18 this column contains the current syn backlog. Send-Q Established: The count of bytes not acknowledged by the remote host. Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.

[Pavel Timofeev]

However on my CentOS 7.4 only ss shows correct Send-Q (i. e. backlog, listen/accept queue) value for listening socket, but netstat doesn't

[Ciro Costa]

Thanks for the in-depth information, Alexander! Just a quick addition: udiag_wqueue might be different than the value you passed to listen(2) if /proc/sys/net/core/somaxconn is smaller than the backlog value set in the syscall. That's because Linux caps the value: elixir.bootlin.com/linux/v4.15/source/net/socket.c#L1479