i dont think you need that. devip calls a protocol specific
garbage collector procedure that will close these hanging
connections for you if it runs out of connections.
/sys/src/9/ip/tcp.c:/^tcpgc
well, the test is a little bit more complicated as it takes
a minimum inactivity time into account.
made a patch that changes the panic into a print:
/n/sources/patch/devip-allconvused-panic
--
cinap
--- Begin Message ---
On Sun Apr 18 16:41:17 EDT 2010, ge...@plan9.bell-labs.com wrote:
> There are limits on the number of concurrent conversations per
> protocol. For UDP, it's currently 1024, for TCP it's currently 1024
> on terminals and 4096 on cpu servers. For ICMP, it's currently 128;
> you may want to raise that. To find the current limits,
>
> grep '>nc = ' /sys/src/9/ip/*.c
it's surprisingly easy to burn through connections since connections
can hang out in Finwait2 for a long time, burning up packets and
connections:
; cpu -c 'cd /net.alt/tcp; x=1??? echo $x($#x)'
1175
i haven't had time to take a look at this issue, but i wonder if acks
during Finwait2 are resetting the timer. this is definately related
to smtp &/| pop.
i sometimes use this script as hostowner to clear out these
connections
x=`{grep -l Finwait2 */status|sed 's:/status::g'}
for(i in $x)
if(~ `{cat $i^/local} *!110 *!25)
>$i^/ctl echo hangup
- erik
--- End Message ---
