ftpd keeps ftp processes alive

[Bart_6]

I just noticed that on one of our ftp servers some ftpd processes are still alive while the connections is aleready disconnected.some are even disconnected for days.

how is this possible,what can I do to find the cause and what could be a solution

[U.SivaKumar_2]

Hi,

Edit /etc/inetd.conf file and modify ftp line like this.
Original Line:

ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l

Modified line:

ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l -t 5

-t 5 option will cause the inactive sessions to timeout after 5 Min. Default timeout is 15 Min.

Now run

#inetd -c



regards,

U.SivaKumar

[Bart_6]

If default timeout is 15 minutes it does not explain why I'm still seeing ftpd processes with ps -ef

[Michael Tully]

What OS version and current patch bundle level?

[U.SivaKumar_2]

Hi,
Sorry misread
OK , ftp processes are alive after even after DISCONNECION.

Give this command

#ndd -set /dev/tcp tcp_keepalive_interval 700000

Default value is 72000000 millisecs .

Edit /etc/rc.config/nddconf for making the changes permanent.

Connect again with ftp ad come back with results.

regards,

U.SivaKumar

[Stanimir]

Hi!
I suppose your ftp is leaving open sockets.
Try #netstat -a | grep ftp
and look at state column: CLOSE_WAIT or
FIN_WAIT. May be you need ndd to
remove them.
Show the results.
Regards

[Greg OBarr]

I have seen this before with some applications that use FTP. We use eMatrix and I have seen it with that application. I had to modify the default timeout for ftpd several months ago, just as was shown above. I don't know if the application was poorly written and just not closing the ftp session properly or if the users were ending the application abnormally. In either case, changing the timeout will solve the problem.

-greg

[Bart_6]

OS: HP-UX 11.11

I found with netstat -a|grep ftp several open sockets,connections with a status TIME_WAIT. After I killed the ftp-processes on unix these connections disappeared.

[rick jones]

It is _highly_ unlikely that a TCP connection in TIME_WAIT could hold a process open. Not impossible mind you, but unlikely. And besides, it would go the other way around :)

TIME_WAIT is the state that a TCP connection enters when that side of the TCP connection was the first to send a FINished segment, has had that FIN ACKnowledged by the remote TCP, and then has received and ACKed a FIN from the remote.

Most often this happens as each side calls close() on the socket. When an application calls close on a socket, it releases its reference to the connection - there is no longer an association between the connection and the process.

Now, it is possible that the ftpd issued a shutdown() call, and the remote did either shutdown() or close(), and then the local FTP never called close. That I would find rather surprising, but it could be investicated by taking a tusc trace (11.X) of the ftpd's.

And by default TIME_WAIT only lasts 60 seconds under HP-UX.

I think there may be something else going-on. One way to try to diagnose would be to run tusc on the ftpd.

Altering the tcp_keepalive_interval will have an effect IFF the ftpd is setting SO_KEEPALIVE. I cannot recall off the top of my head if it does, but again, tusc'ing the ftpd from start to finish could confirm that. Keepalives will only "kill" a TCP connection if the remote never answers them, so if the remote ftp client code has not close()ed his end, no setting to tcp_keepalive_interval will cull a TCP connection.

[Bart_6]

Correct, I have traced these connections not to be of this current problem. The current problem stays that in the ps -ef output i still see ftpd processes: root 25763 762 0 Feb 14 ? 0:00 ftpd: :: STOR