harsher kill than kill -9 ?
Is there any way to kill a process that kill -9 pid won't remove without rebooting? thanks in advance, -Dan
Re: harsher kill than kill -9 ?
I think this was a problem with 2.4.3 kernel (I know I've had it on my system). The fix was to upgrade to 2.4.5 Andrei -- First there was Explorer... Then came Expedition. This summer Coming to a street near you.. Ford Exterminator. -- Andrei Ivanov http://arshes.dyndns.org [EMAIL PROTECTED] 12402354 --
Re: harsher kill than kill -9 ?
On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? No, kill -9 is as harsh as it gets. Have you tried to kill it as root? Walt
Re: harsher kill than kill -9 ?
I think this was a problem with 2.4.3 kernel (I know I've had it on my system). The fix was to upgrade to 2.4.5 Andrei I'm already running 2.4.5... -Dan
Re: harsher kill than kill -9 ?
On Thu, 12 Jul 2001, Walt Mankowski wrote: On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? No, kill -9 is as harsh as it gets. Have you tried to kill it as root? Yea, with -9 and -11... -Dan
Re: harsher kill than kill -9 ?
On Thu, 12 Jul 2001, Joost Kooij wrote: On Thu, Jul 12, 2001 at 11:39:09AM -0400, Daniel Patrick Berdine wrote: On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? Unblock the process in the kernel, so its pending signals can be handled. This is admittedly rather difficult to force from the user side of the kernel barrier. Is there a man page or something I can read to see how to do this? Its my own machine, I have root priviledges, but still, no idea how to unblock a process... Read a good book on unix concepts. That is honestly the best answer I can give you in this limited space and time. Thanks, sounds like a project for another day tho :) -Dan
Re: harsher kill than kill -9 ?
Well, if its a zombie process, it'll go away by itself after a while. Can you send an output of ps aux for that process (or top), please? Andrei -- First there was Explorer... Then came Expedition. This summer Coming to a street near you.. Ford Exterminator. -- Andrei Ivanov http://arshes.dyndns.org [EMAIL PROTECTED] 12402354 --
Re: harsher kill than kill -9 ?
On Thu, Jul 12, 2001 at 11:39:09AM -0400, Daniel Patrick Berdine wrote: On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? Unblock the process in the kernel, so its pending signals can be handled. This is admittedly rather difficult to force from the user side of the kernel barrier. Is there a man page or something I can read to see how to do this? Its my own machine, I have root priviledges, but still, no idea how to unblock a process... Read a good book on unix concepts. That is honestly the best answer I can give you in this limited space and time. Cheers, Joost
Re: harsher kill than kill -9 ?
On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? Unblock the process in the kernel, so its pending signals can be handled. This is admittedly rather difficult to force from the user side of the kernel barrier. Is there a man page or something I can read to see how to do this? Its my own machine, I have root priviledges, but still, no idea how to unblock a process... Thanks, -Dan
Re: harsher kill than kill -9 ?
On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? Unblock the process in the kernel, so its pending signals can be handled. This is admittedly rather difficult to force from the user side of the kernel barrier. Cheers, Joost
Re: harsher kill than kill -9 ?
On Thu, 12 Jul 2001, Andrei Ivanov wrote: Well, if its a zombie process, it'll go away by itself after a while. Can you send an output of ps aux for that process (or top), please? Andrei not zombie... 19355 rothaar9 0 90588 88M 476 D 0.0 17.6 0:01 plot.out from top. I actually had dpkg do the same thing the other day when I tried to install a third part .deb. Eventually got it to work fine, but it got hung up at dpkg --config. I thought it was just a fuke of what I was doing at the time or something, but maybe not... I run dozens of apps very similar to this every day for my work, the only thing special about this one was that I was trying to run it with a certain array as large as possible. It kept segfaulting because I didn't have neough memory I guess, until this one, which just sortof sits there, munching up memory but no CPU (luckily! :) ) The array was 1,000,000 x 2 x 2 x 1 and it was trying to make 100 copies, so I don't blame the machine for complaining a bit, but I'd really like to kill the stupid thing... Thanks, -Dan
Re: harsher kill than kill -9 ?
but by far, the most efficient method is still rebooting -- k h a o s * lamer new name, new look, new ftp: linux.dyn.dhs.org (change FOUR letter) upload something before downloading, or your class C IP banned. - Original Message - From: Joost Kooij [EMAIL PROTECTED] To: Daniel Patrick Berdine [EMAIL PROTECTED] Cc: debian-user@lists.debian.org Sent: Thursday, July 12, 2001 11:36 PM Subject: Re: harsher kill than kill -9 ? On Thu, Jul 12, 2001 at 11:06:57AM -0400, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? Unblock the process in the kernel, so its pending signals can be handled. This is admittedly rather difficult to force from the user side of the kernel barrier. Cheers, Joost -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: harsher kill than kill -9 ?
The `D' tells you that the process is in an uninterruptible disk wait state. This can only be caused by a kernel problem with the i/o routines, a filesystem problem, or a device driver problem. There really isn't anything you can do but restart the machine to get rid of that process unless you're lucky enough to have it return from it's wait (not likely). For some explanation, a problem like this is caused when an application tries to read/write from disk, but the i/o call never returns, and it doesn't result in a timeout either. `kill -9', as most of you know, is used to send SIGKILL to a process. The SIGKILL signal can not be blocked, ignored, or handled by an application in any way, which means that once your application receives a SIGKILL, it's done for. The reason it doesn't work in this situation, however, is that the program needs to accept the signal that's trying to be sent first. It can't do this while it's waiting to return from it's disk activity. If you'd like something to read, check out Advanced Programming in the UNIX Environment (Stevens 1992). It's got some very useful information regarding signals and how they're handled. -David Fuchs Daniel Patrick Berdine wrote: On Thu, 12 Jul 2001, Andrei Ivanov wrote: Well, if its a zombie process, it'll go away by itself after a while. Can you send an output of ps aux for that process (or top), please? Andrei not zombie... 19355 rothaar9 0 90588 88M 476 D 0.0 17.6 0:01 plot.out from top. I actually had dpkg do the same thing the other day when I tried to install a third part .deb. Eventually got it to work fine, but it got hung up at dpkg --config. I thought it was just a fuke of what I was doing at the time or something, but maybe not... I run dozens of apps very similar to this every day for my work, the only thing special about this one was that I was trying to run it with a certain array as large as possible. It kept segfaulting because I didn't have neough memory I guess, until this one, which just sortof sits there, munching up memory but no CPU (luckily! :) ) The array was 1,000,000 x 2 x 2 x 1 and it was trying to make 100 copies, so I don't blame the machine for complaining a bit, but I'd really like to kill the stupid thing... Thanks, -Dan
Re: harsher kill than kill -9 ?
On Thu, Jul 12, 2001 at 12:09:11PM -0400, Daniel Patrick Berdine wrote: | On Thu, 12 Jul 2001, Andrei Ivanov wrote: | | Well, if its a zombie process, it'll go away by itself after a while. | Can you send an output of ps aux for that process (or top), please? | Andrei | | not zombie... | | 19355 rothaar9 0 90588 88M 476 D 0.0 17.6 0:01 plot.out ^^^ IIRC (not at a linux box to check) that column is % of CPU being used. Since it isn't using any CPU it is only a problem for you as far as memory hogging goes. As Joost was indicating, the problem is the process is waiting (blocked) in the kernel; in some sort of system call (maybe sbrk or fork or something else that requires kernel services). The difficulty is that if the kernel just killed it, who would clean up after the kernel? Instead what current implementations do is hold any signals for the process until it returns to userland from inside the kernel. Then it is safe for the kernel to kill it because it isn't in the middle of the kernel anymore. So aside from rebooting, praying, and coming up with a new breakthrough in OS theory, you don't really have anything you can do about it. -D
Re: harsher kill than kill -9 ?
D-Man wrote: On Thu, Jul 12, 2001 at 12:09:11PM -0400, Daniel Patrick Berdine wrote: | On Thu, 12 Jul 2001, Andrei Ivanov wrote: | | Well, if its a zombie process, it'll go away by itself after a while. | Can you send an output of ps aux for that process (or top), please? | Andrei | | not zombie... | | 19355 rothaar9 0 90588 88M 476 D 0.0 17.6 0:01 plot.out This looks a log like the rw_semaphore implementation bug from 2.4.3 (which was supposed to have been fixed in the 2.4.4pre series)... does this mean it's still around in 2.4.5?
Re: harsher kill than kill -9 ?
On Thu, 12 Jul 2001, David Fuchs wrote: The `D' tells you that the process is in an uninterruptible disk wait state. This can only be caused by a kernel problem with the i/o routines, a filesystem problem, or a device driver problem. There really isn't anything you can do but restart the machine to get rid of that process unless you're lucky enough to have it return from it's wait (not likely). For some explanation, a problem like this is caused when an application tries to read/write from disk, but the i/o call never returns, and it doesn't result in a timeout either. `kill -9', as most of you know, is used to send SIGKILL to a process. The SIGKILL signal can not be blocked, ignored, or handled by an application in any way, which means that once your application receives a SIGKILL, it's done for. The reason it doesn't work in this situation, however, is that the program needs to accept the signal that's trying to be sent first. It can't do this while it's waiting to return from it's disk activity. Ok, thanks. Seems odd that theres no way of killing a process.. I don't really know that much about how these things work, but it seems like there should be some way to just purge everything to do with the process from memory or something... Oh well :) Thanks, -Dan
Re: harsher kill than kill -9 ?
On Thu, 12 Jul 2001, Daniel Patrick Berdine wrote: Is there any way to kill a process that kill -9 pid won't remove without rebooting? No. If kill -9 won't kill it there are only three possible causes. 1) The process is a zombie. (It will be marked with a 'Z' in ps). A zombie is a process which has exited but whose parent has not wait()'ed for it yet. Zombie processes take up no resources other than the slot in the process table, so don't worry about this. Once the parent wait()s or exits the zombie will go away on its own. 2) The process is blocked in a kernel system call. (These are marked with a 'D' in ps). Normally this is the result of a hardware problem, removable media media not ready or a down NFS link mounted hard. 3) Kernel bug :}
Re: harsher kill than kill -9 ?
* Daniel Patrick Berdine ([EMAIL PROTECTED]) spake thusly: ... Seems odd that theres no way of killing a process.. I don't really know that much about how these things work, but it seems like there should be some way to just purge everything to do with the process from memory or something... Think of it this way: the process called some kernel function and went (eg. was swapped) away until that function returns. There's no process to kill, only the kernel function = kernel itself. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key One distinguishing characteristic of BOFHen is attention deficit disorder. Put me in front of something boring and I can find a near-infinite number of really creative ways to bugger off. -- Antony De Boer in asr
