> > 3) The socket-state becomes CLOSE_WAIT, and will stay so until the
> > sending process is killed.
>
> This is correct. CLOSE_WAIT means it waits for a close() from the
> application, and a kill closes all open file descriptors.
> Fix: call close() at the right time in your app.
OK, from the kernels point of view this might be correct. The problem is
that none of the failing applications have been mine... sendmail 8.9.0
and several different POP3 daemons. So either all these are broken or the
kernel has failed to notifies the applications. Shouldn't the socket send
an EOF to the application if the peer terminates?
> > 4) If the sending process is killed, the socket-state will turn into
> > LAST_ACK, and will stay so "forever".
> >
> > 5) This "forever", might sometimes only last for a few weeks or months.
>
> This should not happen. What does netstat -t --timers output for such a
> socket?
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 30 22112 130.235.92.230:18697 132.68.1.8:25 CLOSE_WAIT off(0.00/0)
tcp 30 18433 130.235.92.230:6569 132.68.1.8:25 LAST_ACK off(0.00/0)
> LAST-ACK means that it is waiting for the ack of the FIN just send.
> If it does not appear the socket should be destroyed via a timer
> after some time. When the other end retransmits packets (e.g. its FIN)
> it is possible that the timer is always restarted. So what OS is the
> peer running?
In most cases, I have no idea. But in all cases I have known about the
peer OS, it has been MacOS...
> Is there any activity still on the connection (check with tcpdump) ?
No activity.
/Henrik
/ Henrik Laurila, Kryolab ! Tel: office: +46-(0)46-2227697 /
/ Department of Physics ! home: +46-(0)40-960766 /
/ Lund University ! Fax: +46-(0)46-2223637 /
/ Lund, Sweden ! WWW: http://bore.fysik.lu.se /
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/