Just recently I have started an application that then freezes. It shows in the list of processes viewed using something like KDE System Guard or Top but cannot be killed by using either of the above or 'kill' from the command line.
Is there any way of killing these processes? The only way that I have found is to reboot which seems a bit drastic.
Barry Samuels http://www.beenthere-donethat.org.uk The Unofficial Guide to Great Britain
Hi Barry
This is something I have to do quite a lot of...
kill TaskName
Usually does the trick - Best done as root, but with extreme caution.
Regards, Paul.
On Sunday 26 October 2003 2:21 pm, Barry Samuels wrote:
Just recently I have started an application that then freezes. It shows in the list of processes viewed using something like KDE System Guard or Top but cannot be killed by using either of the above or 'kill' from the command line.
Is there any way of killing these processes? The only way that I have found is to reboot which seems a bit drastic.
On 2003.10.26 14:21, Barry Samuels wrote:
Is there any way of killing these processes? The only way that I have found is to reboot which seems a bit drastic.
Normally, a kill command sends the signal SIGTERM which the application can set its own handler for or ask to be blocked or ignored. If the application won't die with a normal kill then you can try sending it SIGKILL with 'kill -KILL' or 'kill -9'. Only use SIGKILL if a normal kill fails as it doesn't give the application any chance to tidy up like deleting temp files, message queues or shared memory.
If the process will not die even with SIGKILL then it is probably in an "uninterruptible sleep" which shows in the 'S' column of ps -l as 'D'. Normally this means it is waiting for disk I/O to comeplete but can be waiting for file I/O on an NFS mounted disk when the 'intr' mount option was not used. If it isn't using NFS then this probably indicates a hardware fault (faulty disk, or disk interrupts being lost) or a kernel bug.
Steve.
Not much left to add :)
On 2003-10-26 18:00:48 +0000 Steve Fosdick lists@pelvoux.nildram.co.uk wrote:
-KILL' or 'kill -9'. Only use SIGKILL if a normal kill fails as it doesn't give the application any chance to tidy up like deleting temp files, message queues or shared memory.
I normally use -3 or -QUIT in between a TERM and KILL. Is there any justification for doing so, or am I just repeating old Unix folklore?
"uninterruptible sleep" which shows in the 'S' column of ps -l as 'D'. Normally this means it is waiting for disk I/O to comeplete but can be
I think that you can run lsof (LiSt Open Files) with the right options to find out what files the process is using, but sometimes that locks up if a filesystem has gone really bad.
On 2003.10.26 21:03, MJ Ray wrote:
I normally use -3 or -QUIT in between a TERM and KILL. Is there any justification for doing so, or am I just repeating old Unix folklore?
If core dumps haven't been disabled via ulimit, SIGQUIT has the side effect of creating a core dump of the program being killed. If you want a backtrace because you're the developer or you intend to submit a bug report this could be very useful.
If this is indeed what you want to do you can reset the ulimit to allow core files first, then send the SIGQUIT:
ulimit -c 102400 # 100Mb (or ulimit -c unlimited) kill -QUIT <pid>
The other thing about SIGQUIT is that it can often be generated from the keyboard so when your program doesn't respond to ^C (SIGINT) you can type ^\ to send it SIGQUIT.
Finally, shells tend to ignore SIGTERM and SIGHUP can usually be used to kill them rather than resorting straight for SIGKILL.
-
bsamuels＠beenthere-donethat.org.uk -
MJ Ray -
Paul -
Steve Fosdick