- Paul Farber <[EMAIL PROTECTED]>:
| Hello all, got a new one for qmail 1.03 users everywhere.
|
| I've had these connections for about a day now. qmail-qread says these
| messages are not in the que, and qmail-qstat equalled the number of
| messages that qmail-qread displayed.
|
| I stopped and restarted the qmail-smtpd daemon (im on a RH 5.1 box so I
| gave it a qmail-smtpd restart. It stopped the tcpserver, supervise, and
| smtpd daemon... but these guys are still here.
|
| Any way of figuring our why they are lingering or how to kill them short
| of a reboot?
|
| BTW... man netstat did not explain the LAST_ACK signal.
|
| Thanks!
|
| tcp 65 25365 mail.f-tech.net:28934 mail.hotmail.com:smtp
| LAST_ACK
| tcp 65 24665 mail.f-tech.net:29812 mail.hotmail.com:smtp
| LAST_ACK
LAST_ACK is not a signal, it's a TCP state. It means the connection
is practically closed down, your end is just waiting for the other
side's ACK of your FIN. Check the TCP connection state diagram in
figure 6, RFC 793. If hotmail.com generates a lot of connections in
this state they sure have a problem. I don't know what you can do
about it, though, as I am no networking expert.
But as far as I can figure out, your host should be retransmitting
that FIN packet once in a while. If the host at the other end is
down, or has been down and come back up, I would expect an ICMP packet
to come along to explain that the connection just isn't there, after
which your side can abort the connection and clean up. But this is
clearly not happening, and here my advice runs dry.
- Harald
