FTP randomly hangs

[ryanc2]

I have an ftp .ksh script that runs on a SCO UNIX box and either "puts" or "gets" files to/from a windows 2000 server. It runs constently throughout the day and sleeps every 8 seconds. Everything works fine except that an ftp session will randomly hang causing the script to lock up. If I run netstat and grep for ftp, it will usually show that session as CLOSE_WAIT, but sometimes ESTABLISHED.

I can then kill the ftp pid and the script will take off again.

Any suggestions on how to troubleshoot this?

Thanks

 

[Salem]

8 seconds seems a bit quick to me - too quick to allow previous ftp TIME_WAIT connections to actually timeout.

I'd try 'netstat -a' to list all connections, and see if there are lots of these about.

I'd also try running at a lower rate - to compare reliability. Similarly, a higher rate may make it fail quicker (which would be good for testing).

> If I run netstat and grep for ftp
What's happening on the W2K side?

Finally, consider the -d (debug) and/or -t(trace) options of FTP. It may shed some light on what is going on.

 

[ryanc2]

On the W2k side, it is reporting a "Timeout Due to Inactivity" message after 900 seconds. Here is the output of the ftp debug:

---> AUTH KERBEROS_V5
'AUTH DERBEROS_V5': command not understood
---> SYST
Please login with USER and PASS.
---> TYPE A
Please login with USER and PASS.
Remote system type is unknown.
Using ascii mode to transfer files.
---> USER ftpuser
---> PASS XXXX
---> CWD hjs/EXPORTS/ADJUSTMENTS
---> PORT 10,12,1,3,13,231
---> NLST WAADJBAY*.DAT

Like I mentioned before, it could perform these same commands hundereds of times without hang ups, but occasionally it will hang at this point...and always this point.

I have run on another UNIX box with no network traffic, and cannot duplicate the problem.

I ran 'netstat -a | grep TIME_WAIT' and there are a ton of entries.

Is it the NLIST command in FTP?

 

[Salem]

> I have run on another UNIX box with no network traffic, and cannot duplicate the problem.
There are a limited number of internet ports, and each one of those TIME_WAIT's is occupying one of them.

My guess is that at 8 seconds, there are enough spare ports to allow them to timeout before you need to re-use them.

If you're running other traffic like browsers and the like, then the available ports will be reduced. I'm guessing that FTP locks up if there are none available when it requests a port, but doesn't recover gracefully when ports become available.

A slower rate (say every 20 seconds) will reduce the number of ports in the TIME_WAIT state because of FTP activity.

 

[dblair]

Not sure abount SCO unix but SRV4 kernels have a TIME_WAIT for ftp connections.