Add init process for zombie fighting and signal handling

[crosbymichael]

This adds a small C binary for fighting zombies. It is mounted under
/dev/init and is prepended to the args specified by the user. You
enable it via a daemon flag, dockerd --init, as it is disable by
default for backwards compat.

You can also override the daemon option or specify this on a per
container basis with docker run --init=true|false.

You can test this by running a process like this as the pid 1 in a
container and see the extra zombie that appears in the container as it
is running.

int main(int argc, char ** argv) {
    pid_t pid = fork();
    if (pid == 0) {
        pid = fork();
        if (pid == 0) {
            exit(0);
        }
        sleep(3);
        exit(0);
    }
    printf("got pid %d and exited\n", pid);
    sleep(20);
}

Fixes #3793
Fixes #24284

Signed-off-by: Michael Crosby crosbymichael@gmail.com

[tonistiigi]

# dockerd -s overlay -D --reaper 2>/daemon.log &
# docker run busybox /nosuchfile
error: No such file or directory
# echo $?
1

# dockerd -s overlay -D 2>/daemon.log &
# docker run busybox /nosuchfile
docker: Error response from daemon: oci runtime error: exec: "/nosuchfile": stat /nosuchfile: no such file or directory.
# echo $?
127

We should add an option to run integration-cli with both modes. I'm sure we have a test for this case.

[cpuguy83]

Looks like this will resolve #3793

[AkihiroSuda]

why rw?

[crosbymichael]

Ok, so as far as flags go, @tonistiigi and I talked about this some. We are not totally sold on what the flag name should be but we have a good idea on how it should work.

On the daemon we will have a bool --init flag. This will be false by default, and if set to true, will run the custom docker init in every container.

On run, we will also have a --init flag that is a nullable bool. If it is not set, we use the daemon default. If it is set to true, we use the docker init for the container, if it is --init=false we will not use the init. This allows us to have bot a daemon wide option and the ability to enable/disable per container, without changing anything for users that don't have this set.

If anyone has a better idea for a flag name let me know.

[crosbymichael]

Updated this to use --init for now on both the daemon and run. You can try out all the various combinations.

[icecrime]

Moving this to code review: I think there no big controversy on the design 👍 I agree with everything in that comment #26061 (comment).

[tonistiigi]

What if we do a lookup and mode check for the entrypoint before actually executing to maintain this behavior?

[crosbymichael]

Like in the docker daemon?

[tonistiigi]

in daemon or containerd

[crosbymichael]

won't work because lookups have to happen inside the container's mount ns after all volumes are mounted because PATH and binaries could live inside them

[tonistiigi]

We already have same hack for cp.

[crosbymichael]

yes, "hack"

[icecrime]

Small questions regarding tests, otherwise LGTM 👍

[justincormack]

typo "were" not "where"

[glensc]

is the /dev abuse really a good idea?

i recall discussion about /run because vendors abused /dev for their early boot dirty work:
https://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html

perhaps just use file named docker-init (or .docker-init) in root filesystem or /lib or /sbin?

[ndeloof]

That's a nice improvement to get docker handle this PID1 issue. But I'm concerned this moves the responsibility to run with --init option into end users hands. For sample, the jenkins docker image uses tiny for same purpose, but end user don't have to even know what a zombie process is.

I suggest one could use some metadata in image to let runtime know such init process is required, for sample by adding to Dockerfile: LABEL io.docker.init='true'

[thaJeztah]

I suggest one could use some metadata in image to let runtime know such init process is required, for sample by adding to Dockerfile: LABEL io.docker.init='true'

In cases where a zombie reaper is required (in most cases, it should not even be needed), it should be added by the image author. I think this PR should be seen as a "last effort" if the image is not under control of the user.

[tianon]

Did the Dockerfile instruction to enable this by default at the image level we discussed make it in to 1.13? 😇