SUMMARY: endless CLOSE_WAIT

 Hi again,


Thanks to Casper Dik and Terry Gardner for suggestions. Unfortunately I could
do nothing. My diagnosis at present is the following:
* during night update of DB, a script restarts DB daemon (routinely)
* usualy nobody uses DB interface between 2am and 5am
* but this time the restart (which is really fast) probably
  occured while somebody used DB interface at exactly that moment
* the interface is CGI, which talks to DB daemon on the port in question
* so the Apache thread or CGI process(es) got crazy and was/were captured 
   somehow in <defunct> state (possibly waitng for response from socket 
  too long while its parent went away).
* I've tried to deal with this <defunct> process using kill or directly
  in /proc but no way.
* finnaly I rebooted server (fortunately we have Saturday today)

Have a nice Sunday! Kind regards,

GB

P.S. I hate <defunct> processes!

************My Query**************************
> >Normaly I run an application which listen on port 22222.
> >But now I cam't start it because the port is "occupied"
> >by ... (I don't know by what)
> >netstat shows:
> >zatoka.49377         zatoka.22222         49152      0 49152      0 
> >CLOSE_WAIT
> >netstat -v shows:
> >zatoka.49377        
> >zatoka.22222         49152 00000000 00000000 49152 00000000 00000000   435  
> >8192 CLOSE_WAIT
> >lsof|grep 22222 or lsof|grep 49377 gives nothing.
> >This close_wait seems to last at list for 10 hours (first problems were
> >reported 2am, now it is 12:00 here).
> >Is there any way to check who (which process, or service or ...what)
> >keeps the port in such state so long ?
> >Or the only possibility is to reboot (production!) server ???
> 
********** Response form Casper Dik <casper (at) holland.sun.com> ********

> pfiles (part of the OS) or lsof (freeware).
> CLOSE_WAIT indicates that a process still has a file descriptor open; so
> you do need to find the process and kill it.
> 
> It could either be a fork()ed of copy of the daemon or a sub process
> which inherited the filedescriptor.
> 
> Casper

******** Response from Terry Gardner <Terry.Gardner (at) Sun.COM>**********
> did you solve this? CLOSE_WAIT is the state where it's waiting for
> LAST_ACK. It'll stay there until it gets it unless you have the stack
> modified.

----------------------EoT-------------------------------------