In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
[1]+ Stopped yum update [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum 6220 pts/0 00:00:00 ps [root@tabby ~]# kill 6214 [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum ##still running! 6221 pts/0 00:00:00 ps [root@tabby ~]# exit logout There are stopped jobs. ##still running! [root@tabby ~]#
As you see, the kill command produces no output here, but if I make up a pid at random it complains no such pid exists.
I'm running a single Athlon 1 gHz processor, if that is important.
When I search Bugzilla for "kill" the only relevant hits are from ages ago in RH 5.1 or so, where a few lines of code run by a non-root user could kill any process regardless of owner (the opposite problem). This was apparently fixed and closed. I considered compiling and running the program as root to see if I had better luck than with kill, but it doesn't really address the issue.
Should I file a Bugzilla report, or am I missing something?
-- David Liguori
Try kill -9 <pid> sometimes kill doesn't work. When in doubt -9 it :) Works everytime. CTRL+Z simply puts it into the background.
Jesus
On Thu, 27 Jan 2005 21:04:16 -0500, David Liguori liguorid@albany.edu wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
[1]+ Stopped yum update [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum 6220 pts/0 00:00:00 ps [root@tabby ~]# kill 6214 [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum ##still running! 6221 pts/0 00:00:00 ps [root@tabby ~]# exit logout There are stopped jobs. ##still running! [root@tabby ~]#
As you see, the kill command produces no output here, but if I make up a pid at random it complains no such pid exists.
I'm running a single Athlon 1 gHz processor, if that is important.
When I search Bugzilla for "kill" the only relevant hits are from ages ago in RH 5.1 or so, where a few lines of code run by a non-root user could kill any process regardless of owner (the opposite problem). This was apparently fixed and closed. I considered compiling and running the program as root to see if I had better luck than with kill, but it doesn't really address the issue.
Should I file a Bugzilla report, or am I missing something?
-- David Liguori
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
David Liguori wrote:
[root@tabby ~]# kill 6214
You're missing a kill signal. I suggest you read the man page on kill: man kill
Ashley M. Kirchner wrote:
David Liguori wrote:
[root@tabby ~]# kill 6214
You're missing a kill signal. I suggest you read the man page on kill: man kill
I did read it: SYNOPSIS kill [ -s signal | -p ] [ -a ] [ -- ] pid ... kill -l [ signal ] signal looks like an optional argument to me. What should it be?
-- David Liguori
On Thursday 27 January 2005 20:29, David Liguori wrote:
I did read it: SYNOPSIS kill [ -s signal | -p ] [ -a ] [ -- ] pid ... kill -l [ signal ] signal looks like an optional argument to me. What should it be?
"man -k signal" output shows:
"signal (7) - list of available signals"
and it's seems pretty comprehensive:
Give "man 7 signal" a shot to see it that helps. As a side note, "skill" is rather handy too.
Regards, Mike Klinke
On Thu, 27 Jan 2005 21:04:16 -0500, David Liguori liguorid@albany.edu wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens: ... As you see, the kill command produces no output here, but if I make up a pid at random it complains no such pid exists.
This is not a bug, this how it is supposed to work.
When you use control-Z from the shell to push a process to the background, the process is also stopped (until you later use the shell's fg or bg command). When a process is in a stopped state any signals are queued up for it (with a few exceptions such as the SIGKILL (-9) signal).
This could be seen by running: cat /proc/6214/status near the end you'll see a line like: ShdPnd: 0000000000004000
Since the default signal that kill(1) sends is a SIGTERM, and SIGTERM is 15 (in file /usr/include/bits/signum.h) and the 15th bit starting from 1 is 0x4000, you'll see that the signal is still "pending".
Only when the process is re-awoken will the signal actually be delivered. And it will only have it's effect when delivered.
On Thu, 2005-01-27 at 21:04 -0500, David Liguori wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
First question, why are you stopping it with Ctrl-Z?? Ctrl-Z puts it to sleep into the background. Why not use Ctrl-C which is the intended approach?
[1]+ Stopped yum update [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum 6220 pts/0 00:00:00 ps [root@tabby ~]# kill 6214 [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum ##still running! 6221 pts/0 00:00:00 ps [root@tabby ~]# exit logout There are stopped jobs. ##still running! [root@tabby ~]#
This is working as intended. You are using the kill command correctly by sending the default signal first (15), the problem is that you put the process to sleep earlier with the Ctrl-Z so it cannot "process" the TERM (15) signal that you have sent. You could at this point bring the process to the foreground waking it up by using the "fg" command, or you could awaken it in the background using the "bg" command. Once the process is awake, it will process the signal and go away.
BTW, I would not recommend, as many people are wont to do, and jump onto the KILL (9) signal. If your process is still writing things to disk (asleep or awake), this signal pulls the proverbial rug out from underneath and you run the risk of ending up with corrupted data depending on the process. Use the KILL (9) signal only as a last resort.
I think most books now say this is the proper order:
Ctrl-C kill -15 kill -9
HTH,
--Rob
Robert Locke wrote:
On Thu, 2005-01-27 at 21:04 -0500, David Liguori wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
First question, why are you stopping it with Ctrl-Z?? Ctrl-Z puts it to sleep into the background. Why not use Ctrl-C which is the intended approach?
[1]+ Stopped yum update [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum 6220 pts/0 00:00:00 ps [root@tabby ~]# kill 6214 [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum ##still running! 6221 pts/0 00:00:00 ps [root@tabby ~]# exit logout There are stopped jobs. ##still running! [root@tabby ~]#
This is working as intended. You are using the kill command correctly by sending the default signal first (15), the problem is that you put the process to sleep earlier with the Ctrl-Z so it cannot "process" the TERM (15) signal that you have sent. You could at this point bring the process to the foreground waking it up by using the "fg" command, or you could awaken it in the background using the "bg" command. Once the process is awake, it will process the signal and go away.
BTW, I would not recommend, as many people are wont to do, and jump onto the KILL (9) signal. If your process is still writing things to disk (asleep or awake), this signal pulls the proverbial rug out from underneath and you run the risk of ending up with corrupted data depending on the process. Use the KILL (9) signal only as a last resort.
I think most books now say this is the proper order:
Ctrl-C kill -15 kill -9
HTH,
--Rob
Thanks for all the help on this.
-- Dave
some other helpful commands jobs - lists your background jobs fg # bring job # to the foreground (so you can hit <ctrl> + C) ps aux (so you can see if you own the process)
At 08:56 AM 1/28/2005, David Liguori wrote:
Robert Locke wrote:
On Thu, 2005-01-27 at 21:04 -0500, David Liguori wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
First question, why are you stopping it with Ctrl-Z?? Ctrl-Z puts it to sleep into the background. Why not use Ctrl-C which is the intended approach?
[1]+ Stopped yum update [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum 6220 pts/0 00:00:00 ps [root@tabby ~]# kill 6214 [root@tabby ~]# ps PID TTY TIME CMD 6179 pts/0 00:00:00 su 6182 pts/0 00:00:00 bash 6214 pts/0 00:00:21 yum ##still running! 6221 pts/0 00:00:00 ps [root@tabby ~]# exit logout There are stopped jobs. ##still running! [root@tabby ~]#
This is working as intended. You are using the kill command correctly by sending the default signal first (15), the problem is that you put the process to sleep earlier with the Ctrl-Z so it cannot "process" the TERM (15) signal that you have sent. You could at this point bring the process to the foreground waking it up by using the "fg" command, or you could awaken it in the background using the "bg" command. Once the process is awake, it will process the signal and go away. BTW, I would not recommend, as many people are wont to do, and jump onto the KILL (9) signal. If your process is still writing things to disk (asleep or awake), this signal pulls the proverbial rug out from underneath and you run the risk of ending up with corrupted data depending on the process. Use the KILL (9) signal only as a last resort. I think most books now say this is the proper order: Ctrl-C kill -15 kill -9 HTH, --Rob
Thanks for all the help on this.
-- Dave
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
Michael Yep Development / Technical Operations RemoteLink, Inc. (630) 983-0072 x164
On Fri, 28 Jan 2005 08:52:22 -0500, Robert Locke rlocke@ralii.com wrote:
On Thu, 2005-01-27 at 21:04 -0500, David Liguori wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
First question, why are you stopping it with Ctrl-Z?? Ctrl-Z puts it to sleep into the background. Why not use Ctrl-C which is the intended approach?
[snip]
This is kind of an aside, but if yum is downloading packages, Ctrl+C will not kill it. Instead, yum will switch to a different mirror to download the packages from. This is handy if it happens to pick a slow mirror. Just hit Ctrl+C and it will try another one (assuming you have it set up to use multiple mirrors). This makes it a little harder to kill, though, during this stage.
Jonathan
Jonathan Berry wrote:
On Fri, 28 Jan 2005 08:52:22 -0500, Robert Locke rlocke@ralii.com wrote:
On Thu, 2005-01-27 at 21:04 -0500, David Liguori wrote:
In another thread a user having problems with yum killed it. I am curious how he accomplished that. When I run yum (or any other command, for that matter), it stalls, and I stop it with ctrl-z, the following happens:
First question, why are you stopping it with Ctrl-Z?? Ctrl-Z puts it to sleep into the background. Why not use Ctrl-C which is the intended approach?
[snip]
This is kind of an aside, but if yum is downloading packages, Ctrl+C will not kill it. Instead, yum will switch to a different mirror to download the packages from. This is handy if it happens to pick a slow mirror. Just hit Ctrl+C and it will try another one (assuming you have it set up to use multiple mirrors). This makes it a little harder to kill, though, during this stage.
Jonathan
Well, it still can work - you just need to hit it several times in a row - worked for me at least - just yesterday. Maxim.
Jesus M. Rodriguez wrote:
Try kill -9 <pid> sometimes kill doesn't work. When in doubt -9 it :) Works everytime. CTRL+Z simply puts it into the background.
I try in order:
kill <pid> kill -2 <pid> kill -15 <pid> kill -9 <pid>
However this would not kill a DEFUNCT process. Anyone got an idea on how to do this?
On Sun, 2005-02-20 at 22:38, James McKenzie wrote:
Jesus M. Rodriguez wrote:
Try kill -9 <pid> sometimes kill doesn't work. When in doubt -9 it :) Works everytime. CTRL+Z simply puts it into the background.
I try in order:
kill <pid> kill -2 <pid> kill -15 <pid> kill -9 <pid>
However this would not kill a DEFUNCT process. Anyone got an idea on how to do this?
A defunct process is also called a zombie. You can not kill something that is already dead. :)
Such processes usually result from the parent being killed or exiting with out sending the exit code to the child process.
As far as know these will hang around until you reboot the system. Would be good to try to identify the program that is generating the zombies and see if there is a fix. It really should clean up after itself.
On Sun, 20 Feb 2005 20:38:05 -0700, James McKenzie jjmckenzie51@earthlink.net wrote:
I try in order:
kill <pid> kill -2 <pid> kill -15 <pid> kill -9 <pid>
You should really use the symbolic symbol names (use kill -l to list them). kill -s INT kill -s TERM kill -s KILL
The SIGINT signal is usually what Control-C sends, and typically indicates a keyboard/interactive interrupt. It may or may not terminate a program, depending on what the program desires to do. SIGTERM is the standard signal used to tell a program to shut down (and is the default one sent by the kill command if no signal is specified). SIGKILL is usually the last resort, it will imemdiately kill any processes that is killable (and will not allow the program to clean up after itself).
There are also a couple other signals that sometimes are used to shut down processes: SIGHUP is automatically sent to all child processes of your shell when you log out of your shell; and so most interactive commands will cleanly shut down when receiving it (just like a SIGTERM). SIGQUIT is also sometimes used to tell processes to shut down, but is usually more abrupt than SIGTERM or SIGHUP, almost like an emergency shutdown rather than a graceful shutdown.
Be aware of killing processes more harshly than necessary. Never just do a kill -9 (SIGKILL) unless you've tried everything else first! You could perhaps leave lock files laying around, or even cause corrupted files or databases (and you don't want to chance corrupting your RPM database).
Note that the behavior of Control-C in a shell is really a property of the pseudo-tty driver. You can in fact change it to use another key. Try running "stty -a" to list the current "special" keys. The "intr" is the keystroke that causes an interrupt (SIGINT). The "quit" keystroke (usually Control-) sends a SIGQUIT...which will usually terminate most programs, even those that ignore or trap Control-C.
However this would not kill a DEFUNCT process. Anyone got an idea on how to do this?
Defunct processes (also called zombies) are already dead, and thus can't be killed again.
If you see defunct processes showing up in your process listing, then look to see what the parent process is. The defunct process entry will disappear either when the parent is itself killed, or if the parent process reaps it. Other than consuming a slot in the process table, a defunct process otherwise consumes no system resources--no CPU, no disk, no files, and no memory (except perhaps just a small handful of bytes).
You only need to worry about defunct processes if they tend to stick around a long time and you accumulate a lot of them; in which case it's the parent process that is to blame.
On Sun, 20 Feb 2005 23:00:15 -0500, Scot L. Harris webid@cfl.rr.com wrote:
Such [zombie] processes usually result from the parent being killed or exiting with out sending the exit code to the child process.
As far as know these will hang around until you reboot the system. Would be good to try to identify the program that is generating the zombies and see if there is a fix. It really should clean up after itself.
You've got the direction (parent->child) reversed.
A zombie is always the result of it's parent process, never it's own fault. Killing the parent process will always get rid of any zombies; you don't need to reboot unless the parent itself can't be killed.
What really happens is when a process dies (for whatever reason), there is a small amount of status information that is saved so the parent process later can tell why it's child died and if it was "successful" or not. This status information, which primarily includes an exit code, is usually just a few bytes in size. But the kernel saves it until the parent process gets around to asking for it (which when it does so is called "reaping" the child process). As long as the kernel is remembering those few status bytes, the zombie process entry stays in the process listing. Of course there is no real process (it has since died and all it's memory/resources released back to the OS). A zombie will stay as long as the parent process ignores it and fails to ask for its exit status code, or until the parent itself dies, whichever occurs first.
Whenever almost any process dies, zombies are created. But most parent processes (like bash for example) immediately reap the zombie, so you'll almost never see them. However, some parent processes are not designed properly to react to dead children in a timely manner, so you may see zombie processes. Again, it's the parent process to blame.
On Sun, 2005-02-20 at 23:29, Deron Meranda wrote:
On Sun, 20 Feb 2005 23:00:15 -0500, Scot L. Harris webid@cfl.rr.com wrote:
Such [zombie] processes usually result from the parent being killed or exiting with out sending the exit code to the child process.
As far as know these will hang around until you reboot the system. Would be good to try to identify the program that is generating the zombies and see if there is a fix. It really should clean up after itself.
You've got the direction (parent->child) reversed.
A zombie is always the result of it's parent process, never it's own fault. Killing the parent process will always get rid of any zombies; you don't need to reboot unless the parent itself can't be killed.
What really happens is when a process dies (for whatever reason), there is a small amount of status information that is saved so the parent process later can tell why it's child died and if it was "successful" or not. This status information, which primarily includes an exit code, is usually just a few bytes in size. But the kernel saves it until the parent process gets around to asking for it (which when it does so is called "reaping" the child process). As long as the kernel is remembering those few status bytes, the zombie process entry stays in the process listing. Of course there is no real process (it has since died and all it's memory/resources released back to the OS). A zombie will stay as long as the parent process ignores it and fails to ask for its exit status code, or until the parent itself dies, whichever occurs first.
Whenever almost any process dies, zombies are created. But most parent processes (like bash for example) immediately reap the zombie, so you'll almost never see them. However, some parent processes are not designed properly to react to dead children in a timely manner, so you may see zombie processes. Again, it's the parent process to blame.
-- Deron Meranda
So if the parent process crashes all of the child processes will be cleared? I thought the parent process had to issue an _exit() (or something similar) to get the child process status so it would exit cleanly. If it did not do that then the child process sits around waiting for the parent which is no longer running so it stays forever.
I could still have that wrong. Been awhile since I did that kind of coding.
On Sun, 20 Feb 2005 23:46:56 -0500, Scot L. Harris webid@cfl.rr.com wrote:
So if the parent process crashes all of the child processes will be cleared?
When a parent process dies, all of it's children (whether currently running or if they're zombies), are "inherited" by the main init process, always process ID 1. And init will always immediately reap any zombies. (Init is really a fake process which serves as the process-face to the kernel itself.) So in effect, if the parent process of a zombie dies, then the zombies will immediately be reaped and disappear almost immediately.
I thought the parent process had to issue an _exit() (or something similar) to get the child process status so it would exit cleanly.
The parent needs to call one of the wait() system calls [which includes wait(), waitpid(), wait3(), wait4()]. That will return to the parent the exit code that the kernel has been remembering; and which also "reaps" the zombie and makes it disappear. [Or, instead, the parent can tell the kernel to do auto-reaping via the SA_NOCLDWAIT signal action flag.]
The exit() call is performed by a child process when it wishes to pass back a specific exit code. This is done automatically in C/C++ when a return is made from main(). But, even if a child doesn't call exit() because it terminated some other way (like a core dump), the parent must still call wait().
It can be a little trickier on Linux, especially if you start talking about advanced subjects like multithreaded processes and the clone() system call. But the most common case is the child calls exit() and the parent calls wait(). The time in between the two calls is when a zombie exists.
If it did not do that then the child process sits around waiting for the parent which is no longer running so it stays forever.
When a child dies, it dies. It doesn't need to wait around on any other process. Of course a zombie may result, which only means that the parent hasn't yet recognized that the child has died. The only exception is when the child process is currently being traced (such as being debugged)..in which case the tracing program must detach before the child actually dies.
Deron Meranda wrote:
On Sun, 20 Feb 2005 23:46:56 -0500, Scot L. Harris webid@cfl.rr.com wrote:
So if the parent process crashes all of the child processes will be cleared?
When a parent process dies, all of it's children (whether currently running or if they're zombies), are "inherited" by the main init process, always process ID 1. And init will always immediately reap any zombies. (Init is really a fake process which serves as the process-face to the kernel itself.) So in effect, if the parent process of a zombie dies, then the zombies will immediately be reaped and disappear almost immediately.
So is this a bug in Firefox?
james 17993 17988 5 08:13 ? 00:01:19 /usr/lib/firefox-1.0/firefox-bin -UILocale en-US james 18003 17993 0 08:14 ? 00:00:00 [netstat] <defunct>
If so, I will look for a bug entry at Bugzilla.
On Sun, 2005-02-20 at 20:38 -0700, James McKenzie wrote:
Jesus M. Rodriguez wrote:
Try kill -9 <pid> sometimes kill doesn't work. When in doubt -9 it :) Works everytime. CTRL+Z simply puts it into the background.
I try in order:
kill <pid> kill -2 <pid> kill -15 <pid> kill -9 <pid>
However this would not kill a DEFUNCT process. Anyone got an idea on how to do this?
AFAIK a defunct (zombied) process cannot be killed. It can only be removed from the process table by rebooting.
-- James McKenzie With assistance, Now running 2.6.11rc3, Software Suspend 2 and ibm-acpi .1 Need a home for my .rpm
On Mon, 2005-02-21 at 00:21 -0500, Deron Meranda wrote:
On Sun, 20 Feb 2005 23:46:56 -0500, Scot L. Harris webid@cfl.rr.com wrote:
So if the parent process crashes all of the child processes will be cleared?
When a parent process dies, all of it's children (whether currently running or if they're zombies), are "inherited" by the main init process, always process ID 1. And init will always immediately reap any zombies. (Init is really a fake process which serves as the process-face to the kernel itself.) So in effect, if the parent process of a zombie dies, then the zombies will immediately be reaped and disappear almost immediately.
NOT always. Some processes leave zombies that last forever (until the next reboot).
I thought the parent process had to issue an _exit() (or something similar) to get the child process status so it would exit cleanly.
The parent needs to call one of the wait() system calls [which includes wait(), waitpid(), wait3(), wait4()]. That will return to the parent the exit code that the kernel has been remembering; and which also "reaps" the zombie and makes it disappear. [Or, instead, the parent can tell the kernel to do auto-reaping via the SA_NOCLDWAIT signal action flag.]
The exit() call is performed by a child process when it wishes to pass back a specific exit code. This is done automatically in C/C++ when a return is made from main(). But, even if a child doesn't call exit() because it terminated some other way (like a core dump), the parent must still call wait().
It can be a little trickier on Linux, especially if you start talking about advanced subjects like multithreaded processes and the clone() system call. But the most common case is the child calls exit() and the parent calls wait(). The time in between the two calls is when a zombie exists.
If it did not do that then the child process sits around waiting for the parent which is no longer running so it stays forever.
When a child dies, it dies. It doesn't need to wait around on any other process. Of course a zombie may result, which only means that the parent hasn't yet recognized that the child has died. The only exception is when the child process is currently being traced (such as being debugged)..in which case the tracing program must detach before the child actually dies.
-- Deron Meranda
On Mon, 21 Feb 2005 10:10:34 -0600, Jeff Vian jvian10@charter.net wrote:
On Mon, 2005-02-21 at 00:21 -0500, Deron Meranda wrote: NOT always. Some processes leave zombies that last forever (until the next reboot).
No, zombies are not permanent.
Zombies will *always* disappear as soon as their parent process wait()s on them, or their parent process dies too. It's not necessary to reboot (although a reboot certainly will work too). How long a zombie sticks around depends only upon it's parent process.
Are you perhaps thinking of a process that's hung in a kernel-locked mode (uninterruptable sleep state, indicated by a "D" in the ps output)? Those processes generally can not be killed except by reboot, or if whatever they were blocked on becomes available again. But they are most definitely not zombie (defunct) processes.
Zombie processes are spawned by a parent process that terminates before receiving the childs signal that they have completed. The Zombie is waiting on acknowledgement from the parent process, thus they run forever, or until the next reboot or someone kills them.
They WILL NOT go away after the parent process dies. This was incorrectly stated in a previous email.
If you are programming this, you can turn off the signaling of the parent/child process to make the child not wait until the parent responds and the child will do it's thing, then cleanly exit. This also frees up the parent to go about something else, rather than waiting on the child, which may not complete.
On Mon, 21 Feb 2005 11:21:36 -0600, William Wilson williamwilson@uwmail.com wrote:
Zombie processes are spawned by a parent process that terminates before receiving the childs signal that they have completed. The Zombie is waiting on acknowledgement from the parent process, thus they run forever, or until the next reboot or someone kills them.
This is absolutely incorrect. I suggest you read any of Steven's UNIX programming books.
"...[the child] terminates first, when it calls exit .... It then becomes a zombie: a process that has terminated, but whose parent is still running but has not yet waited for the child."
You might also want to read this from the Unix FAQ: http://www.faqs.org/faqs/unix-faq/faq/part3/section-13.html
What you are talking about is called an "orphan" process: one whose parent has died first, but that is still alive. All orphans are adopted by process 1 (init). An orphan and a zombie are two different things.
A zombie process is already dead and not running. It can not run, be spawned, or be killed. It can not possibly wait on anything, including it's parent, or do anything. A zombie has no memory, no code, no process counter, no CPU time, nothing. The *kernel* on the other hand will remember the zombie until it's parent either 1) dies, or 2) calls one of the wait() system calls, or 3) the parent had previously told the kernel it doesn't care about dead children.
The signaling you talk about is done by the kernel; not the zombie process.
They [zombies] WILL NOT go away after the parent process dies. This was incorrectly stated in a previous email.
Try to find one that doesn't go away! I've never seen one in 15 years of Unix programming. Yes, technically, what happens is that when the parent process dies it will be adopted by process number 1 (init). But init (aka the kernel) always reaps dead children immediately. So the end effect is that whenever a parent dies, all of it's zombie children are immediately reaped and disappear.
If you are programming this, you can turn off the signaling of the parent/child process to make the child not wait until the parent responds and the child will do it's thing, then cleanly exit. This also frees up the parent to go about something else, rather than waiting on the child, which may not complete.
Regardless of any signalling (SIGCHLD), the child *never* waits on anything before it is allowed to die. It just dies. The *only* things that can delay or keep a process from dying when it wants to are 1) it is being traced, 2) it is in the stopped state. (And technically a process in the stopped state by definition can not be dying). Neither of these conditions have anything to do with what a parent process may or may not be doing.
The parent of any non-lazily coded application can certainly do useful work at all times without being blocked while monitoring it's children. This is why the SIGCHLD asynchronous signal is sent, and also why there are the wait3() and wait4() system calls with the WNOHANG flag. (Or, if you're coding directly to the low-level clone() system call any other signal can be set up instead).
The cause of almost all zombies (that stay around more than a millisecond) is either incorrectly or lazily coded parent processes. But if you kill the parent, the zombies will disappear. If this is not the case then file a kernel bug immediately.
And the only bad effect of a zombie process is that it occupies one of the process "slots" in the kernel table. It otherwise can not consume any resources (memory, cpu, etc), nor can it hold locks, keep files or sockets open, or block any other process in any way.
Deron Meranda wrote:
On Mon, 21 Feb 2005 11:21:36 -0600, William Wilson williamwilson@uwmail.com wrote:
Zombie processes are spawned by a parent process that terminates before receiving the childs signal that they have completed. The Zombie is waiting on acknowledgement from the parent process, thus they run forever, or until the next reboot or someone kills them.
This is absolutely incorrect. I suggest you read any of Steven's UNIX programming books.
"...[the child] terminates first, when it calls exit .... It then becomes a zombie: a process that has terminated, but whose parent is still running but has not yet waited for the child."
You might also want to read this from the Unix FAQ: http://www.faqs.org/faqs/unix-faq/faq/part3/section-13.html
What you are talking about is called an "orphan" process: one whose parent has died first, but that is still alive. All orphans are adopted by process 1 (init). An orphan and a zombie are two different things.
A zombie process is already dead and not running. It can not run, be spawned, or be killed. It can not possibly wait on anything, including it's parent, or do anything. A zombie has no memory, no code, no process counter, no CPU time, nothing. The *kernel* on the other hand will remember the zombie until it's parent either 1) dies, or 2) calls one of the wait() system calls, or 3) the parent had previously told the kernel it doesn't care about dead children.
The signaling you talk about is done by the kernel; not the zombie process.
They [zombies] WILL NOT go away after the parent process dies. This was incorrectly stated in a previous email.
Try to find one that doesn't go away! I've never seen one in 15 years of Unix programming. Yes, technically, what happens is that when the parent process dies it will be adopted by process number 1 (init). But init (aka the kernel) always reaps dead children immediately. So the end effect is that whenever a parent dies, all of it's zombie children are immediately reaped and disappear.
If you are programming this, you can turn off the signaling of the parent/child process to make the child not wait until the parent responds and the child will do it's thing, then cleanly exit. This also frees up the parent to go about something else, rather than waiting on the child, which may not complete.
Regardless of any signalling (SIGCHLD), the child *never* waits on anything before it is allowed to die. It just dies. The *only* things that can delay or keep a process from dying when it wants to are
- it is being traced, 2) it is in the stopped state. (And technically
a process in the stopped state by definition can not be dying). Neither of these conditions have anything to do with what a parent process may or may not be doing.
The parent of any non-lazily coded application can certainly do useful work at all times without being blocked while monitoring it's children. This is why the SIGCHLD asynchronous signal is sent, and also why there are the wait3() and wait4() system calls with the WNOHANG flag. (Or, if you're coding directly to the low-level clone() system call any other signal can be set up instead).
The cause of almost all zombies (that stay around more than a millisecond) is either incorrectly or lazily coded parent processes. But if you kill the parent, the zombies will disappear. If this is not the case then file a kernel bug immediately.
And the only bad effect of a zombie process is that it occupies one of the process "slots" in the kernel table. It otherwise can not consume any resources (memory, cpu, etc), nor can it hold locks, keep files or sockets open, or block any other process in any way.
Thank you, gentlemen, for pursuing this thread. It has been both interesting and informative.
:-) In civil courtroom circles, I believe the exchanges would qualify as expert dueling!
-
Ashley M. Kirchner -
David Curry -
David Liguori -
Deron Meranda -
James McKenzie -
Jeff Vian -
Jesus M. Rodriguez -
Jonathan Berry -
Maxim Eremeev -
Michael Yep -
Mike Klinke -
Robert Locke -
Scot L. Harris -
William Wilson