Process is not closing

[Removed by request]

I'm using Ubuntu 12.04 dev and sometimes I'm seeing zombie processes which are using no virtual memory and not closing. They will only close if their parent process closes. For example if I start lxterminal and opening htop I will see that there are 2 lxterminal processes. One normal process and one forked process which is a zombie. The same happens sometimes with lxdm-binary if I login into my desktop. In the attachments is a screenshot from such processes.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/915158/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Removed by request (removed3425744)]

It is not possible for me to say exactly which package is causing this problem. It can affect every application so it is a global problem. Maybe it is related to bash or the Linux kernel.

[Removed by request (removed3425744)]

I have found a command which will cause a process to turn into a zombie process:

dash -c '(sleep 3 & sleep 6)'

If "sleep 3" finishes it will turn into a zombie process and only close if "sleep 6" finishes. With bash all is working fine (but bash is creating "bash -c (sleep 3 & sleep 6)" 2 times) but the most applications are using sh (which is a symlink to dash).

[Jilles Tjoelker (jilles)]

You can see the same problem with any shell with a command like

(sleep 3 & exec /bin/sleep 6)

because most versions of /bin/sleep do not clean up zombies (here, a zombie from an inherited child process).

Dash does not consider the existence of a background process a reason to fork for an external command (that needs to be execve()'ed). Therefore you may see zombies if you start some background jobs and the final command is external and does not clean up zombies it did not start itself. As a workaround you can add a builtin at the end, for example

(sleep 3 & sleep 6; exit $?)

With bash, this does not happen because bash appears to fork always for an external command unless it is the only thing to be run in the process at all. However, this policy results in more process creations than necessary and therefore poorer performance.

POSIX does not appear to say much about whether the shell should allow commands to inherit child processes in this manner. However, a shell is definitely not required to fork as much as bash does.

[Removed by request (removed3425744)]

Maybe as a feature dash could catch the SIGCHLD signal to handle the zombie process much faster.

[Jilles Tjoelker (jilles)]

Catching SIGCHLD in dash does not help in this case, since dash is already gone (execve'ed) by the time the SIGCHLD would come.

[Removed by request (removed3425744)]

In my example the dash process still exists until both sleeps have been finished. I have written a small testcase in C to check if its an applications fault if there are zombie processes:

#include <stdio.h>
#include <unistd.h>

int main()
{
 FILE *pipe;

 if((pipe = popen("echo", "r")) == 0)
 {
 }
 /*pclose(pipe);*/
 usleep(100000000);
 return 0;
}

This example will cause sh to get a zombie process if echo has finished until the main application finishes. But if I'm uncommenting /*pclose(pipe);*/ the zombie process will successfully clean up. So I'm assuming its the fault of the parent process if there are zombie processes because it isn't closing the related file descriptor.