2

When I'm logged to a tmux session from two different computers, I'd like to be able to trace the amount of pending data on the sockets of both tmux session. To test this I logged to computer A and to computer B, then from computer B I used ssh to login to computer A. From each console I attached to the same tmux session and started running a script which prints the iteration number from 1 to 100M. Indeed, I see that the numbers of the iterations printed in the local (A) console are larger than the numbers printed in the remote console (B) since it takes time for the messages to travel to the remote computer

[user@server00 ~]$ lsof | grep tmux | grep unix
tmux      1073     user    4u     unix 0xf6dc2ac0       0t0   18681 socket
tmux      1073     user    5u     unix 0xf6dc3840       0t0   18682 socket
tmux      1073     user    6u     unix 0xf137ed00       0t0   19768 socket
tmux      1073     user    7u     unix 0xf6dc2880       0t0   18683 /tmp/tmux-1000/default
tmux      1073     user    8u     unix 0xf6cbcd80       0t0   22647 /tmp/tmux-1000/default
tmux      1073     user   14u     unix 0xf137ef40       0t0   12146 /tmp/tmux-1000/default
tmux      1092     user    4u     unix 0xf6cbd200       0t0   24848 socket
tmux      1092     user    5u     unix 0xf6cbef40       0t0   24849 socket
tmux      1092     user    6u     unix 0xf6cbed00       0t0   24850 socket
tmux      1177     user    4u     unix 0xf137fcc0       0t0   19947 socket
tmux      1177     user    5u     unix 0xf137fa80       0t0   19948 socket
tmux      1177     user    6u     unix 0xf137c240       0t0   19949 socket
[user@server00 ~]$ netstat -a | grep tmux
unix  2      [ ACC ]     STREAM     LISTENING     18683    /tmp/tmux-1000/default
unix  3      [ ]         STREAM     CONNECTED     12146    /tmp/tmux-1000/default
unix  3      [ ]         STREAM     CONNECTED     22647    /tmp/tmux-1000/default

Since I see only the path of /tmp/tmux-1000/default I was hoping to see its size increasing but its size is always 0

[user@server00 ~]$ ls -l /tmp/tmux-1000/default
srwxrwx---. 1 user user 0 Feb  9 10:45 /tmp/tmux-1000/default

How can I see the data pending on the socket, and how do I know if the socket becomes congested?

1

I don't believe that's how sockets work. You keep reading until it's empty, the size isn't communicated through the socket, and it's not to my knowledge displayed anywhere on the socket that's created on the filesystem /tmp/tmux-1000/default.

excerpt

Unix Socket FAQ - 2. Questions regarding both Clients and Servers (TCP/SOCK_STREAM)

I don't think that write() can legitimately return 0. read() should return 0 on receipt of a FIN from the peer, and on all following calls.

So yes, you must expect read() to return 0.

Source: Unix Socket FAQ

Also if you look at how reading from a socket is often done, you're essentially in a while (true) loop, continuously reading until the connection is explicitly terminated. You have no way to know how much data is pending in the socket.

excerpt

while ( true )
    {
        unsigned char packet_data[256];
        unsigned int maximum_packet_size = sizeof( packet_data );
...

Source: SENDING AND RECEIVING PACKETS

So to answer your question, the only way to know how much data is on the socket, is to read it all!

References

  • Thank you very much for your detailed answer, I certainly agree with you. So my next questions are what is the meaning of the file size for unix domain sockets? And is it always 0? – e271p314 Feb 9 '14 at 19:06
  • 1
    @e271p314 - It's always zero. If you look at the permissions bits for that "file" notice "srwxrwx---." this tells you it's a socket, and so you'd typically ignore the size in this scenario. – slm Feb 9 '14 at 19:09
2

I'm afraid slm's answer (currently marked as correct) is incorrect on a number of fronts.

First off, the OP was asking whether there was a way to tell externally whether a process had data pending on an AF_UNIX socket. slm's answer requires modification to the process itself. Generally, netstat is useful in externally examining a process over which you cannot control the behavior. It can be useful to know whether a process has unread data, which can indicate that the process is not servicing its socket properly with reads (i.e. maybe it has a bug, or is misconfigured, or a thread has died).

Second, slm indicates that you can't do it even within the process, except by reading the socket until it's empty. Also wrong. A process can use the SIOCINQ/FIONREAD ioctl to detect how much data is pending in a socket, without reading it (I prefer FIONREAD, because it means the same thing in more contexts and is thus more generally recognized than SIOCINQ, which is specific to sockets). See the unix(7) man page.

Finally, on Linux there is in fact a way to do what the OP actually requested (externally detect the amount of data pending on a unix domain socket), by using the ss program, rather than netstat. ss -ax will do the trick. It is kind of like netstat on steroids. See the ss(8) man page.

References

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.