Dan Peterson writes: > > While investigating an issue with CVS server processes (pserver v1.11), I > noticed a number of processes that didn't appear to be talking to a client > anymore and had been hanging around for many hours or even days.
What state does netstat say the connections are in? TCP/IP has a problem with clients disappearing without correctly closing the connection. This is typically caused by a network outage, a system crash, or a power failure (including someone turning off the power without shutting the machine down first). Because TCP/IP was designed to allow network connections to survive temporary network failures, such vanished clients are not detected quickly, and they may not be detected at all. If a server tries to send data to such a client, the lack of ACKs from the client will eventually (typically a few hours) cause the host system to declare the connection dead and inform the server process. On the other hand, if the server is waiting to read data from the client, the fact that the client has disappeared will never be noticed. Most systems have implemented a "Keep Alive" mechanism where a server can ask the system to periodically send a packet on otherwise idle connections to detect vanished clients, but that takes longer to declare the connection dead (up to a day or longer), not all systems support it, and some systems appear to support it but don't really do anything. CVS uses it where it's available. > Some of the processes had a parent process ID of 1 which tells me the > process maintaining the network connection had exited and the process had > been adopted by "init". That indicates a bug in CVS. It would be helpful if you could attach to such a process with a debugger and get a traceback. -Larry Jones How many presents do you think I'd forfeit for just one clean smack upside Susie's head? -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
