|
Home > Archive > Unix Shell > September 2007 > How to kill CLOSE_WAIT without reboot
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to kill CLOSE_WAIT without reboot
|
|
|
|
| Lew Pitcher 2007-09-20, 1:30 pm |
| On Sep 20, 1:26 am, G=F6khan Alt nsoy <gokhanaltin...@gmail.com> wrote:
> Hi,
>
> How to kill CLOSE_WAIT without reboot system.
> System is HP-UX
Have the server application perform a close() on it's outbound socket.
| |
| Gökhan Alt nsoy 2007-09-20, 7:21 pm |
| On Sep 20, 4:49 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> On Sep 20, 1:26 am, G=F6khan Alt nsoy <gokhanaltin...@gmail.com> wrote:
>
>
>
> Have the server application perform a close() on it's outbound socket.
Application is Apache with SSL and weblogic plugin.
This problem occurs in 2-3 week period.it seems leaking out.
| |
| Barry Margolin 2007-09-21, 1:27 am |
| In article <1190265971.188243.128020@n39g2000hsh.googlegroups.com>,
Gökhan Altınsoy <gokhanaltinsoy@gmail.com> wrote:
> Hi,
>
> How to kill CLOSE_WAIT without reboot system.
> System is HP-UX
Kill the process that has the connection open.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Gökhan Alt nsoy 2007-09-21, 1:27 pm |
| On Sep 21, 6:07 am, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <1190265971.188243.128...@n39g2000hsh.googlegroups.com>,
> G=F6khan Alt nsoy <gokhanaltin...@gmail.com> wrote:
>
>
>
> Kill the process that has the connection open.
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***
"kill -9 PID " couldnt kill the process 
| |
| Bill Marcum 2007-09-21, 7:22 pm |
| On Fri, 21 Sep 2007 13:00:23 -0000, Gökhan Alt nsoy
<gokhanaltinsoy@gmail.com> wrote:
>
> "kill -9 PID " couldnt kill the process
>
That could mean one of three things:
1) Someone else owns the process. Only the owner or root can kill it.
2) The process is a zombie, existing only in the process table until its
parent calls "wait()".
3) The process is in an uninterruptible wait state due to a hardware problem,
and may require a reboot.
--
Interfere? Of course we should interfere! Always do what you're
best at, that's what I say.
-- Doctor Who
| |
| Gökhan Alt nsoy 2007-09-22, 1:17 pm |
|
>
> That could mean one of three things:
> 1) Someone else owns the process. Only the owner or root can kill it.
> 2) The process is a zombie, existing only in the process table until its
> parent calls "wait()".
> 3) The process is in an uninterruptible wait state due to a hardware problem,
> and may require a reboot.
>
> --
> Interfere? Of course we should interfere! Always do what you're
> best at, that's what I say.
> -- Doctor Who
In this case , It is "3" . Is there a way to understand which hardware
problem ?
Thanks
| |
| Maxwell Lol 2007-09-22, 7:16 pm |
| Gökhan Alt nsoy <gokhanaltinsoy@gmail.com> writes:
> In this case , It is "3" . Is there a way to understand which hardware
> problem ?
It's probably a bug in the hardware device driver, caused by a problem
in the hardware.
Can you switch the hardware?
| |
| Gökhan Alt nsoy 2007-09-23, 7:29 am |
| On Sep 22, 9:35 pm, Maxwell Lol <nos...@com.invalid> wrote:
>
> It's probably a bug in the hardware device driver, caused by a problem
> in the hardware.
>
> Can you switch the hardware?
You mean which hardware ?
whole system or only ethernet card ?
Thanks
| |
| Maxwell Lol 2007-09-23, 1:31 pm |
| Gökhan Alt nsoy <gokhanaltinsoy@gmail.com> writes:
> On Sep 22, 9:35 pm, Maxwell Lol <nos...@com.invalid> wrote:
>
>
>
> You mean which hardware ?
>
> whole system or only ethernet card ?
In general, if you have a problem and are trying to determine the
cause, you switch components so that the same comoponent failes in two
different systems the same way. If this is true, the component is bad.
If you have another Ethernet card, try that. Personally, I'd also look
into using a different type of card.
I did not say it was a hardware problem, by the way. But if it is, a
different card might help determine if it's true.
It's more likely a bug in the driver, which is why changing to a
different Ethernet card by a different vendor might be useful.
Googling CLOSE_WaIT might offer some other ideas:
http://unix.derkeiler.com/Mailing-L...1/msg00367.html
http://www.sunmanagers.org/pipermai...ary/007068.html
http://www.sunmanagers.org/archives/1999/1208.html
http://www-1.ibm.com/support/docvie...rss=ct662tivoli
http://archive.linuxvirtualserver.o...9/msg00403.html
| |
| Barry Margolin 2007-09-24, 1:25 am |
| In article <icods4-1gd.ln1@don.localnet>,
Bill Marcum <marcumbill@bellsouth.net> wrote:
> On Fri, 21 Sep 2007 13:00:23 -0000, Gökhan Alt nsoy
> <gokhanaltinsoy@gmail.com> wrote:
> That could mean one of three things:
> 1) Someone else owns the process. Only the owner or root can kill it.
> 2) The process is a zombie, existing only in the process table until its
> parent calls "wait()".
That's obviously not possible in this case. A zombie can't have open
sockets.
> 3) The process is in an uninterruptible wait state due to a hardware problem,
> and may require a reboot.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Gökhan Alt nsoy 2007-09-24, 1:25 am |
| Thanks everybody for useful knowledge.
I will monitor system under this new knowledge.
| |
| Juha Laiho 2007-09-25, 1:26 pm |
| =?iso-8859-1?q?G=F6khan_Alt_nsoy?= <gokhanaltinsoy@gmail.com> said:
>
>
>In this case , It is "3" . Is there a way to understand which hardware
>problem ?
It could also be a a bug in the operating system kernel code.
You might be able to gain some insight into the issue by looking at the
WCHAN field of 'ps' listing; that shows where the process is waiting.
Then map that data into what is in kernel at that address. Apologies,
it's a few years since I did this kind of work, so the details evade me;
anyway you should be able to find from kernel the point where your
application is waiting, and deduce from that at least some extra knowledge
as to what is going wrong.
If you have OS and hardware support contracts with HP for the machine
in question you might try filing a case for them.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
|
|
|
|
|