Subject: stuck idle processes

From: Laszlo Vecsey <[email-masked]>
Date: Tue, 16 Mar 1999 07:35:30 -0500 (EST)

I'm noticing a bunch of ftpd processes hanging around because (i think) of
users logging in anonymously and then being disconnected, most likely a
dynamic user or static user that has shut their machine off.. with the way
tcp/ip works the process wont die until they're back on the net.

I have the timeouts set to -t600 and -T3600, which seem reasonable. Are
you guys running scripts periodically to kill these processes?

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 16 Mar 1999 08:36:27 -0500 (EST)

On Tue, 16 Mar 1999, Laszlo Vecsey wrote:

> I'm noticing a bunch of ftpd processes hanging around because (i
> think) of users logging in anonymously and then being disconnected,
> most likely a dynamic user or static user that has shut their machine
> off.. with the way tcp/ip works the process wont die until they're
> back on the net.
> 
> I have the timeouts set to -t600 and -T3600, which seem reasonable.
> Are you guys running scripts periodically to kill these processes?

I see something similar.

First, I noticed that a lot of people are using Netscape and IE.  The
browsers tend to lean a connection open and idle until the user closes the
program or moves on to another site.  When/if the user issues another
command, the browser closes this control connection and starts another.
My timeouts were originally 600/3600 and seemed reasonable until I started
closely watching what was happenning.  To combate these needless idle
control connections, I switched to 300/300 for timeout values.  This does
not appear to have affecteded too many command-line ftp users, but had a
marked improvement on the number of idle control connections laying about.
Note that none of these are orphaned control connections.  When the idle
timeout kicks in they close as normal.

As I watch my servers, I'll notice a TCP socket (sometimes two or three,
never very many) hung in FIN_WAIT1.  Usually, these are data connection
sockets, but occassionally they are control connection sockets as well.  
At the point where I'm investigating, there are no processes associated
with the socket; it's hanging on trying to close down.  Normally, the TCP
stack timers for these sockets will eventually time out.

Every now and then, I'll see a FIN_WAIT1 socket whose counters are being
reset by an ACK packet from the remote host.  This stray ACK appears to be
the result of a lame firewall/proxy trying to hold the connection in case
the user ever returns (fat chance, you dumb firewall/proxy).

I've determined the sockets _are_ having their counters reset by the
remote host by installing firewall rules for those IP/sockets preventing
INCOMING packets FROM the remote host on the single remote socket.  The
counters immedeately start clocking down and, when they timeout, the
socket closes.

For the past few weeks, I've been letting the sockets go, to see what
happens.  Eventually they go away.  Either that means the remote
firewall/proxy finally gave up on the user's returning (unlikely), or it
reassigned the IP number to another user which caused the connection to
reset (very likely), or there's something in my kernel which is finally
closing the socket (unlikely).

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195