Re: kill -KILL fails to kill process
others). This can happen when your process blocks on pending file I/O. The process opens a file descriptor, could even be a socket, and asterisk does only file I/O and network I/O. file I/O works fine so it can't be a problem (everything else works on the same filesystem. get what it's waiting for (hopefully), then move on. At that very moment, the kill signal would be delivered and the process would die after a day - still not killed. i'm going to reboot this today. BTW asterisk is threaded. possibly main thread is stopped, but others not. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
1. The process hangs in disk wait (flag D in ps' STAT column). This often means there's a hardware problem with your disk or controller (or a driver bug), or a network problem if you use NFS. not this for sure. no NFS, no filesystem is blocked. 2. The process was suspended (SIGSTOP). In this case there is the flag T in ps' STAT column. Try sending a SIGCONT to the process. tried (kill -19) then kill -9, doesn't help. Such a dead entry in the process table is called a zombie process. In ps' STAT column there is the Z flag. no Z flag. 887 ?? Ts 0:02,20 asterisk -C /centrala/etc/asterisk.conf ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
On Saturday 20 September 2008 08:35:53 Wojciech Puchar wrote: 1. The process hangs in disk wait (flag D in ps' STAT column). This often means there's a hardware problem with your disk or controller (or a driver bug), or a network problem if you use NFS. not this for sure. no NFS, no filesystem is blocked. 2. The process was suspended (SIGSTOP). In this case there is the flag T in ps' STAT column. Try sending a SIGCONT to the process. tried (kill -19) then kill -9, doesn't help. Such a dead entry in the process table is called a zombie process. In ps' STAT column there is the Z flag. no Z flag. 887 ?? Ts 0:02,20 asterisk -C /centrala/etc/asterisk.conf Some processes suspend themselves directly on a certain condition, or because they try to read from a terminal. Example: # cat -n test.sh 1 #!/bin/sh 2 3 read LINE; 4 echo $LINE; # sh test.sh /dev/tty [1] 103 # ps -axo pid,command,stat 103 PID COMMAND STAT 103 sh test.sh TJ # kill -CONT 103 [1]+ Stopped sh test.sh /dev/tty However, this one can be killed: # kill -KILL 103 [1]+ Killed: 9 sh test.sh /dev/tty I'm not entirely sure why, but it could be cause the tty is valid. Anything in asterisk that reads from a terminal (maybe a closed stdin?) -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
On Fri, Sep 19, 2008 at 11:41 AM, Steve Franks [EMAIL PROTECTED] wrote: Which I thought was impossible. Neophyte question, no doubt, but googling was less than helpful (which probably means I'm fubar, no doubt). Anyway, I have a certain common X app (xmms) that likes to hang (since my last buildworld, it seems) when when it's right about to open a file-choosing dialog. The only way to get rid of it is to reboot. Now, given the behavior, I'd have to suspect something underlying as the true source of the problem, but shouldn't kill kill it anyway - I mean, isn't there some way to kill a process that's stuck waiting on a child process? I haven't figured out how to ps -ax grep | some neublous file dialog process yet...so I'm sort of stuck wanting to kill the parent... I remember the first time this happened to me. I was stunned. I thought kill -9 (or kill -KILL) would kill any process. Even the manual page for kill, kill(1), says that this signal is non-catchable, non-ignorable. In my experience, there's only one condition that will cause this (perhaps those more experienced here than I know of others). This can happen when your process blocks on pending file I/O. The process opens a file descriptor, could even be a socket, and leaves it marked as blocking. The kernel then blocks the process while awaiting I/O in the buffers. In this blocked state, the signal is prevented from being delivered. If you left the process open long enough, perhaps assuming it's not completely hung, the process would get what it's waiting for (hopefully), then move on. At that very moment, the kill signal would be delivered and the process would die (as you wanted it to so very long ago when you delivered that signal to it). I don't run xmms so perhaps some other kind soul here will know what's going on. However, that's why your process didn't die. Andy -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
On Sep 19, 2008, at 10:41 AM, Steve Franks wrote: The only way to get rid of it is to reboot. Now, given the behavior, I'd have to suspect something underlying as the true source of the problem, but shouldn't kill kill it anyway - I mean, isn't there some way to kill a process that's stuck waiting on a child process? Delivery of signals can be delayed if the process is blocked in a system call, until that call completes and returns control to the process in userland. That includes kill -9, unfortunately... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
Steve Franks wrote: Which I thought was impossible. Neophyte question, no doubt, but googling was less than helpful (which probably means I'm fubar, no doubt). Anyway, I have a certain common X app (xmms) that likes to hang (since my last buildworld, it seems) when when it's right about to open a file-choosing dialog. The only way to get rid of it is to reboot. Now, given the behavior, I'd have to suspect something underlying as the true source of the problem, but shouldn't kill kill it anyway - I mean, isn't there some way to kill a process that's stuck waiting on a child process? I haven't figured out how to ps -ax grep | some neublous file dialog process yet...so I'm sort of stuck wanting to kill the parent... If you can't kill a process (even with SIGKILL), it means that the process currently can't be put on the run queue, because only processes that are able to run can receive signals. Given that, such a situation usually has one of these three reasons: 1. The process hangs in disk wait (flag D in ps' STAT column). This often means there's a hardware problem with your disk or controller (or a driver bug), or a network problem if you use NFS. 2. The process was suspended (SIGSTOP). In this case there is the flag T in ps' STAT column. Try sending a SIGCONT to the process. 3. The process terminated, but the parent process failed to pick up the exit code. In this case, the process needs to retain an entry in the process table (shown by ps) in order to record the exit code until it is picked up, even though the process itself is gone. Such a dead entry in the process table is called a zombie process. In ps' STAT column there is the Z flag. This usually indicates a programming error (a.k.a. bug) in the parent process. You can get rid of the zombie by killing the parent process. Then the zombie will be inherited by the next process in the hierarchy (up to the init process 1 if required) which will then pick up the exit code and release the process entry. There can be other reasons on occasion, but those three are the most common ones. Simply look at the STAT column in the ps(1) output for the process in question. It will tell you the reason why the process is stuck. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kill -KILL fails to kill process
If you can't kill a process (even with SIGKILL), it means that the process currently can't be put on the run queue, because only processes that are able to run can receive signals. Given that, such a situation usually has one of these three reasons: Clearly and I/O block is my specific problem, given the behavior. That term signal in the man page did seem like kill is not the brute-force method for making a process go away. Suprising no one has cooked up something more 'lethal'... Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
