On Tuesday, February 10, 2015, Soares Chen <soares.chen@gmail.com> wrote:

> This only happens when the script is running inside a shell spawned by
> `docker exec`. When running under normal system and under `docker
> run`, there is no defunct process.
>
> This bug is first discovered when I run nvm in docker
> (https://github.com/creationix/nvm/issues/650). It was then discovered
> that Docker's nsenter did not properly handle the SIGCHLD signal
> raised from zsh. (https://github.com/docker/libcontainer/pull/369)
> Even though it is now been fixed by Docker, I am not sure why zsh
> would cause this bug in the first place.
>

(Someone more knowledgeable may be able to correct any misconceptions I
have about docker.)

I'm not exactly a docker expert, but my understanding is that docker
incorporates (is built on?) the relatively recent Linux feature of "PID
namespaces".  Under a PID namespace, the first process started is assigned
PID 1and is expected to behave like the "init" process in a traditional
Unix/Linux system, and be the ultimate manager of all the other processes
spawned within the namespace.

Zsh is not designed to assume that role.  In particular, when processing a
script, it will optimize process handling and perform an implicit "exec" of
the final command in the script, so that it need not hang around waiting
for that process to exit, assuming that it's own parent will reap it.  In a
"docker exec" there is no parent to do so.