Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy always 5 connections with no program attached?
    primarykey
    data
    text
    <p>This question is similar to <a href="https://serverfault.com/questions/51499/network-port-open-but-no-process-attached">Network port open, but no process attached?</a> and <a href="https://serverfault.com/questions/311009/netstat-shows-a-listening-port-with-no-pid-but-lsof-does-not?lq=1">netstat shows a listening port with no pid but lsof does not</a>. But the answers to them can't solve mine, since it is so weird. </p> <p>I have a server application called <code>lps</code> that waits for tcp connections on port 8588.</p> <pre><code>[root@centos63 lcms]# netstat -lnp | grep 8588 tcp 0 0 0.0.0.0:8588 0.0.0.0:* LISTEN 6971/lps </code></pre> <p>As you can see, nothing is wrong with the listening socket, but when I connect some thousand test clients(written by another colleague) to the server, whether it's 2000, 3000, or 4000. There have always been 5 clients(which are also random) that connect and send login request to the server, but cannot receive any response. Take 3000 clients as an example. This is what the <code>netstat</code> command gives:</p> <pre><code>[root@centos63 lcms]# netstat -nap | grep 8588 | grep ES | wc -l 3000 </code></pre> <p>And this is <code>lsof</code> command output:</p> <pre><code>[root@centos63 lcms]# lsof -i:8588 | grep ES | wc -l 2995 </code></pre> <p>That 5 connections are here:</p> <pre><code>[root@centos63 lcms]# netstat -nap | grep 8588 | grep -v 'lps' tcp 92660 0 192.168.0.235:8588 192.168.0.241:52658 ESTABLISHED - tcp 92660 0 192.168.0.235:8588 192.168.0.241:52692 ESTABLISHED - tcp 92660 0 192.168.0.235:8588 192.168.0.241:52719 ESTABLISHED - tcp 92660 0 192.168.0.235:8588 192.168.0.241:52721 ESTABLISHED - tcp 92660 0 192.168.0.235:8588 192.168.0.241:52705 ESTABLISHED - </code></pre> <p>The 5 above shows that they are connected to the server on port 8588 but no program attached. And the second column(which is <code>RECV-Q</code>) keeps increasing as the clients are sending the request.</p> <p>The links above say something about NFS mount and RPC. As for RPC, I used the command <code>rcpinfo -p</code> and the result has nothing to do with port 8588. And NFS mount, <code>nfssta</code> output says <code>Error: No Client Stats (/proc/net/rpc/nfs: No such file or directory).</code></p> <p>Question : How can this happen? Always 5 and also not from the same 5 clients. I don't think it's port conflict as the other clients are also connected to the same server IP and port and they are all properly handled by the server.</p> <p>Note: I'm using Linux <code>epoll</code> to accept client requests. I also write debug code in my program and record every socket(along with the clients' information) that <code>accept</code> returns but cannot find the 5 connections. This is <code>uname -a</code> output:</p> <pre><code>Linux centos63 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux </code></pre> <p>Thanks for your kind help! I'm really confused.</p> <hr> <p><em><strong>Update</strong></em> 2013-06-08: After upgrading the system to CentOS 6.4, the same problem occurs. Finally I returned to <code>epoll</code>, and found <a href="https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/" rel="nofollow noreferrer">this page</a> saying that set listen fd to be non-blocking and <code>accept</code> till <code>EAGAIN</code> or <code>EWOULDBLOCK</code> error returns. And yes, it works. No more connections are pending. But why is that? The <em>Unix Network Programming Volume 1</em> says </p> <pre><code>accept is called by a TCP server to return the next completed connection from the front of the completed connection queue. If the completed connection queue is empty, the process is put to sleep (assuming the default of a blocking socket). </code></pre> <p>So if there are still some completed connections in the queue, why the process is put to sleep?</p> <p><em><strong>Update</strong></em> 2013-7-1: I use <code>EPOLLET</code> when adding the listening socket, so I can't accept all if not keeping accept till <code>EAGAIN</code> encountered. I just realized this problem. My fault. Remember: always <code>read</code> or <code>accept</code> till <code>EAGAIN</code> comes out if using <code>EPOLLET</code>, even if it is listening socket. Thanks again to Matthew for proving me with a testing program.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload