kill ftp session on ftp server

[Tammy Liang]

Is there a way to kill ftp session on ftp server for hp-ux system?
I can see the ftp session via "netstat -a".

Thanks for any help.

[Dave Olker]

Hi Tammy,

The only way I know of to forcibly close a connected TCP connection is to use ndd with the "tcp_discon" or "tcp_discon_by_addr" parameters.

To use this syntax you need the pointer to the TCP instance data, which you can retrieve by calling ndd with the "tcp_status" parameter.

For example:

# ndd -get /dev/tcp tcp_status
TCP dst snxt suna swnd cwnd rnxt rack rwnd
rto mss [lport,fport] state
0000000042d958a8 015.023.137.245 30310eb5 30310eb5 00008000 001203e0 2613803d 2613803d 000080
00 00500 04096 [c07b,1770] TCP_ESTABLISHED


You need to correctly identify the connection you're interested from the returned list, which is usually done by finding the correct local and remote IP address/port combinations and the state of the connection.

The first field in the returned list is the TCP instance number, so if you wanted to remove the connection shown in the example above you would use the tcp_discon syntax as follows:


# ndd -set /dev/tcp tcp_discon 0x0000000042d958a8


The tcp_discon parameter is not a supported parameter, so you need to use caution when using this syntax.

I hope this helps.

Regards,

Dave

[Dave Olker]

Hi again,

I found the following document that explains the need for using EXTREME caution when using ndd to shutdown socket connections. I thought I would include it here for your benefit and the benefit of other ITRC forum readers.

------------------------------------------

Use EXTREME caution in using ndd to shutdown socket connections


QUESTION
A powerful function of ndd in 11.x is the ability to "disconnect" a TCP connection and/or "clean-up" a TCP socket. This is done with one of the following ndd "tunables":

tcp_discon - Terminate a TCP connection
tcp_discon_by_addr - Terminate a TCP connection
tcp_fin_wait_2_timeout - Close idle fin waits

Please use and recommend these with GREAT CAUTION!


ANSWER
Typically these get used when someone is wanting to know "how do I clean up a socket?". There is always more to the story that needs to be learned before using ndd.

The reason for great concern is twofold. The first is that we need to address the "real" issue of why these socket connections are "hanging around" and not just cover it up by severing it. The real issue in these cases is almost always an application issue or a operational issue. It is rarely a network issue. The second reason is that use of the tcp_discn* options MAY cause data loss or corruption!

Looking at the most common socket "states":

ESTABLISHED:

If a socket is in an ESTABLISHED state, we clearly should not be blowing it away as there is still an application running that has the connection open. If this is the case, work on the application issue, and if needed, terminate the application, not the socket.

CLOSE_WAIT:

In this case there is still a local application that has the connection open and the same principal applies as does the "ESTABLISHED" case. Often the user will swear that the application has been terminated. I have yet to see a case where this is true. It is sometimes the case that the main program that created (or accept(2)ed) the socket has terminated but a child is still referencing the socket. In any case, the public domain lsof(1) command is your friend in determining which process(s) is still referencing the socket.

Once this is determined, the customer (or the application provider) will need to determine if the application is supposed to still have the socket open and, if not, what the application problem is. It may be the case that the application has yet to finish reading data from the socket. If you "terminate" the socket, the data is "terminated" as well. Not a good thing to do unless you know the application.

Do NOT rely on the output of netstat -an to see if there is unread data on the socket because 11.x will almost always report 0 bytes of data in the Recv-Q even when data is present.

FIN_WAIT* (FIN_WAIT_1/FIN_WAIT_2):

This state is actually the "other end" of a connection that is in CLOSE_WAIT (no they are not "the same"!) In the case of a FIN_WAIT* state, the local application has done a "final close(2)" on the local socket, that is, all processes that may have referenced the socket are now gone. In this case, the local TCP has send a TCP packet to the remote with the FIN flag send (often called a "FIN packet"). The remote may have acknowledged the FIN flag (FIN_WAIT_2) or not (FIN_WAIT_1). In either case, the other end has not yet indicated that it is "done" with the connection.

This is actually a very unique state(s), in that a socket may be in this state and will have no application referencing it. In this case, and this case alone, lsof will NOT show an application that has a file descriptor pointing to the socket. The local TCP is now just waiting for the other end of the connection to tell us it has read all the data and is done with the connection as well. It is never appropriate to shutdown such a connection without knowing what is going on with the other end of the connection. IF you know the situation at the other end of the connection (e.g. the remote system is shutdown), then you may use ndd if you have real need to.

There have been issues where the application on the other end of the connection took over 30 minutes to do what it needed to do and close the other end of the connection. In one particular case where this was true, the local socket (FIN_WAIT_2) was "shut down" after 10 minutes and the remote aborted. The job had been running for almost a week on 10 interconnected hp9000s; the whole job had to be restarted from scratch.

This brings up the point of, why do you "need" to "shutdown" the socket?

Usually this is for one of two reasons. A real problem is when trying to start or restart an application (typically a server process) we get an error from the bind(2) system call indicating that the address is "in use". This usually indicates that we are trying to bind a TCP port number to the socket that is already being used.

This may be a time when you will need to use ndd to "shutdown" a socket that is in FIN_WAIT*. HOWEVER... it also indicates that the server process is not really written in the manner it "should be". A server that binds a specific port number to a socket (most do) should also be using "setsockopt(s, SO_REUSEADDR)" to let the port number be "reused". This is the way most well written server apps work and then it does not matter if there is an "old" socket still around in a state such a FIN_WAIT*. The server will still be able to (re)start.

So please DO take careful note of what ndd (and the lab) says about the tcp_discon* variables:


>> UNSUPPORTED ndd tunable parameters on HP-UX:
>> -------------------------------------------
>> This set of parameters are not supported by HP and modification of
>> these tunable parameters are not suggested nor recommended.

[A. Clay Stephenson]

Plan B.

Determine the PID of the ftpd daemon on the server using ps -ef and then kill PID. All that is needed is a SIGTERM so that a kill -15 PID, the default kill signal, will suffice. This will not kill the client's ftp process but the connection will be closed.

[rick jones]

Definitely go with Plan B, with the possible variant of using lsof to find the FTP PID associated with the endpoint you see in netstat.

As Dave points-out, the ndd stuff is only for those "otherwise we are well and truly fubar" situations when something has to happen _right now_ and the offending (usually broken) application cannot be fixed immediately.

[Tammy Liang]

Thanks all for the advise.

I can not see the ftp session via ps -ef, therefore I can not kill the PID of ftp.
However, I do able to see the ftp session via netstat -a. I do try to use lsof to find the ftp PID, and can not find it.
I don't have ndd on the server (hp-ux 10.20).

Will, I think I just have to kill the ftp process from client system.

[Muthukumar_5]

We can kill the ftp sessions using ps -ef and kill command itself.

Check the settings of /etc/inetd.conf for ftpd as,

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

client> ftp server
root
ftp>

server> ps -ef | grep -v grep | grep ftp
root 23454 23432 0 02:14:48 pts/0 0:00 ftp server
root 23455 759 0 02:14:48 ? 0:00 ftpd: client: connected: IDLE

now kill the 23454 which having tty (pts/0)

It will do your requirement.

[A. Clay Stephenson]

You can definitely see the PID of ftpd using ps -ef on 10.20; your other method would be to use netstat -a

netstat -a | grep "tcp" | grep -i "ESTABLISHED"

The Foreign address column should have hostname.portnumber. You can then use lsof to search for this portnumber and get the PID of ftpd although it should be just as easy to do a ps -ef | grep ftpd. Whatever method you choose, be careful to clobber only the desired PID because there may be multiple ftpd's running at the same time.

[Petr Simik_1]

try lsof
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.71/
to get more informations than netstat

#lsof |grep ftp

[rick jones]

In what state do you find the FTP connection in netstat?

If it is LISTEN, then the process is actually inetd.

If it is FIN_WAIT_2 it suggests you have a client that may have closed its session with RST instead of FIN. Even on 10.20 a few FIN_WAIT_2 connections - they aren't sessions anylonger as the ftpd would be gone aren't really a big deal

[Tammy Liang]

I post the netstat -a, ps -ef and lsof results below.

Thanks for any help...

# netstat -a | grep ftp
tcp 0 0 akad01.ftp englab75.akd.goo.1024 FIN_WAIT_2
tcp 0 0 *.ftp *.* LISTEN
udp 0 0 *.tftp *.*

@ akad01 : /home/appmgr
# ps -ef | grep englab75
root 21771 20922 1 14:00:09 pts/0 0:00 grep englab75

@ akad01 : /home/appmgr
# lsof | grep englab75

@ akad01 : /home/appmgr
#

@ akad01 : /home/appmgr
#

[rick jones]

given your netstat output, you indeed have a FIN_WAIT_2 connection. That is consistent with there no longer being an ftpd, and with the remote client system doing an "abortive" close of the connection.

IIRC, there is a nettune on 10.20 that allows you to set an arbitrary (and thus somewhat dangerous) fin wait timeout. Otherwise, I do not recall if the 10.20 ftpd set SO_KEEPALIVE, but if it did, the connection should die after two hours.

In any event, a single FIN_WAIT_2 connection on a box is not a terribly big concern. You could leave it there until the end of the epoch and it wouldn't really affect stuff.