First question - under CentOS 5, if I created non LVM partitions on a server with 6 disks - 2 disks are RAID 1 (OS), how do I remind myself or inquire the type of RAID of the remaining 4 disks (RAID 1 or RAID 5), without having to reboot?
Second question - A newly installed server consisting of CentOS 5.2, straight off the DVD, I invoke a command by hand, realize I want to kill it soon after (logged in as root). I issue ps auwx|grep name_of_command, get the PID, and issue kill -9 PID. ps auwx|grep name_of_command is still running.
The command is NOT part of any scheduled job. Why won't the process die? How else can I kill it without a system reboot? The command does not get invoked with a script, and is not a script itself - just a standalone binary. I tried CNTL-Z and CNTL-C. I finally killed the terminal it was running from. Nothing works.
pkill doesn't work, either.
Thanks.
Scott, CISSP
Scott R. Ehrlich wrote:
First question - under CentOS 5, if I created non LVM partitions on a server with 6 disks - 2 disks are RAID 1 (OS), how do I remind myself or inquire the type of RAID of the remaining 4 disks (RAID 1 or RAID 5), without having to reboot?
If they are 4 independent disks then you should just see them as standalone disks, if they were in RAID 1 or RAID 5 there would not be 4 disks, there might be 2 for 2xRAID 1s, or 1 with RAID 5. Assuming your using hardware raid of course. If you are using hardware raid depending on the controller/driver you can query it for it's configuration. If your using software raid it should be pretty easy to determine it's configuration as well(last I ran software raid I would just cat /proc/mdstat)
Second question - A newly installed server consisting of CentOS 5.2, straight off the DVD, I invoke a command by hand, realize I want to kill it soon after (logged in as root). I issue ps auwx|grep name_of_command, get the PID, and issue kill -9 PID. ps auwx|grep name_of_command is still running.
The command is NOT part of any scheduled job. Why won't the process die?
Is the process state "D" or "Z" ? Frequently either of these states can trigger an unkillable process. Sometimes "Z" (zombies) can be killed but often times they can't be directly killed. And if the process is in "D" then it is stuck waiting for I/O(most often) and you have to wait for it to complete, or reboot, sometimes going to single user mode and back again works as well, and sometimes killing other processes that the stuck one depends on can sometimes free it up so it can die.
If the process is zombied you can try to find the parent process (if there is one) with ps -efx, and kill that sometimes that can cause the child to die as well, doesn't always work though.
nate
On Tue, 2009-01-13 at 10:04 -0800, nate wrote:
<snip>
Second question - A newly installed server consisting of CentOS 5.2, straight off the DVD, I invoke a command by hand, realize I want to kill it soon after (logged in as root). I issue ps auwx|grep name_of_command, get the PID, and issue kill -9 PID. ps auwx|grep name_of_command is still running.
The command is NOT part of any scheduled job. Why won't the process die?
Is the process state "D" or "Z" ? Frequently either of these states can trigger an unkillable process. Sometimes "Z" (zombies) can be killed but often times they can't be directly killed. And if the process is in "D" then it is stuck waiting for I/O(most often) and you have to wait for it to complete, or reboot, sometimes going to single user mode and back again works as well, and sometimes killing other processes that the stuck one depends on can sometimes free it up so it can die.
It's been a long time, so please forgive any FUD here.
IIRC, zombies are processes that have ended but can not be "cleaned up". This can happen when a parent has died before the child ends, when a parent exists but is "sleeping" (for whatever reason: it may be waiting on another event, waiting for I/O that never completes, ...).
IIRC, when the parent has died, then PPID you'll see is "1". But the zombie will still be un-killable because it can not complete the termination process (the parent it has to notify no longer exists). I can't recall any way to eliminate these with a re-boot. I can't recall if I ever tried a telinit to see if run level changes would kill it. I suspect not.
If the parent exists and signals are not disabled or otherwise handled, the killing of the parent may cause the zombie to flee. This is most common, IIRC, when the parent is awating an event notification.
If a "clean" termination is desired, the parent must support some signal processing, e.g. SIGHUP, SIGUSER1, ... (man 7 signal). If it does, then things like removal of temporary files and telling the children to "STOP THAT" can be done.
That's all I can recall without some actual work.
If the process is zombied you can try to find the parent process (if there is one) with ps -efx, and kill that sometimes that can cause the child to die as well, doesn't always work though.
nate
<snip sig stuff>
HTH
On Tue, 13 Jan 2009, William L. Maltby wrote:
On Tue, 2009-01-13 at 10:04 -0800, nate wrote:
<snip>
Second question - A newly installed server consisting of CentOS 5.2, straight off the DVD, I invoke a command by hand, realize I want to kill it soon after (logged in as root). I issue ps auwx|grep name_of_command, get the PID, and issue kill -9 PID. ps auwx|grep name_of_command is still running.
The command is NOT part of any scheduled job. Why won't the process die?
Is the process state "D" or "Z" ? Frequently either of these states can trigger an unkillable process. Sometimes "Z" (zombies) can be killed but often times they can't be directly killed. And if the process is in "D" then it is stuck waiting for I/O(most often) and you have to wait for it to complete, or reboot, sometimes going to single user mode and back again works as well, and sometimes killing other processes that the stuck one depends on can sometimes free it up so it can die.
I discovered, by chance, the Xen kernel was getting in the way. I booted to the non-Xen kernel and all is well.
Scott
Hi,
First of all: On Tue, Jan 13, 2009 at 12:54, Scott R. Ehrlich scott@mit.edu wrote:
... realize I want to kill it soon after (logged in as root). I issue ps auwx|grep name_of_command, get the PID, and issue kill -9 PID. ps auwx|grep name_of_command is still running.
*NEVER* get used to using kill -9, unless you tried everything else (kill [same as kill -TERM], kill -HUP, kill -USR1, kill -INT, etc.) before that. Using kill -9 does not give the chance to the process to clean up after himself, so it may leave invalid files or even corrupt data. Of course there will be situations where nothing else works, but it should *NOT* be used unless as a last resort.
On Tue, Jan 13, 2009 at 13:53, William L. Maltby CentOS4Bill@triad.rr.com wrote:
IIRC, zombies are processes that have ended but can not be "cleaned up".
Right.
Cleaning up processes (which basically accounts for getting the output status [and maybe closing some file descriptors although I don't think so]) is responsability of the parent process (which is the process that started it, except when that one already died, in which case processes are "adopted" by init which takes care of cleaning them up).
Zombies indicate a problem with the parent process, not with the zombie process itself.
This can happen when a parent has died before the child ends
Wrong. In that case, the child process will be "adopted" by init, which among other things is responsible for cleaning up these processes.
when a parent exists but is "sleeping" (for whatever reason: it may be waiting on another event, waiting for I/O that never completes, ...).
Right. Another reason is bad programming, if the programmer forked a child but never included code to reap them when they die.
IIRC, when the parent has died, then PPID you'll see is "1".
Right, that's when a process is "adopted" by init.
However, init will clean up the "adopted" processes (unless init is hung or something) so you shouldn't have zombies whose parent is init.
HTH, Filipe
-
Filipe Brandenburger -
nate -
Scott R. Ehrlich -
William L. Maltby