SYN_SENT sockets

[Rob Saunders]

I've recently encountered a problem where sockets finish in a SYN_SENT state.

There are two client-server processes (a and b)that talk to each other on the same machine via sockets. After restarting process b, the client processes (a) attempt to reconnect to b but get stuck in the SYN_SENT state. There are approx 120 of these (a) client processes, but surely this is not an enormous amount of processing for a 6 CPU N-class with 4GB RAM? The workaround on this machine is to gradually reintroduce the client processes rather than allow them all to attempt to reconnect at once.

I cannot recreate this problem on a single CPU A-class machine which easily handles the same configuration, accepting all 120 (nearly) simultaneous connections from the client processes...

What are other possibilities for SYN_SENT sockets remaining in that state? Kernel config? H/w failure (not evident)? Software? OS Patch Level?...

[I've noticed in the daemons log that the rpcbind.. "could not create rmtcall fd ticlts" message appears. Is "lts" used for local socket connections? Could this be related?]

TIA

Rob

[Ron Kinner]

In 11.0 and later there is an ndd variable:

tcp_conn_request_max:

Maximum number of outstanding inbound connection requests.
[1, - ] Default: 20 connections

Perhaps adjusting this upwards might help though it does seem strange that a single CPU box has no problems.

ndd -set /dev/tcp tcp_conn_request_max 120

and to make it stay after a reboot edit /etc/rc.config.d/nddconf

to add

TRANSPORT_NAME[x]=tcp
NDD_NAME[x]=tcp_conn_request_max
NDD_VALUE[x]= 120

where x is 0 if this is the first entry or 1 + the last entry's value.

Also seems strange that the client processes do not just resend the SYN if they don't get a reply. Pretty stupid to get locked up because a packet got lost. The basic assumption of TCP/IP is that packets will get lost.


Ron