Understanding session behavior

[joshma]

I'm trying to understand when running dumb-init under a session (i.e. not using --single-child) is useful, and I'm having a hard time reproducing the problem case. Here's a script I'm running that just runs yes as both background and foreground:

#!/bin/sh
yes > /dev/null &
yes > /dev/null

And then I'm running dumb-init -c -- /script.sh:

$ ps aux | grep sh
...
docker   13014  0.8  0.0   1100     4 pts/0    Ss+  19:57   0:00 dumb-init -c -- /bin/sh script.sh
docker   13020  0.0  0.0   4448   776 pts/0    S+   19:57   0:00 /bin/sh script.sh
docker   13033  0.0  0.0   9760  1028 pts/1    S+   19:57   0:00 grep sh

$ ps aux | grep yes
...
docker   13021 99.2  0.0   4352   640 pts/0    R+   19:57   0:10 yes
docker   13022  101  0.0   4352   692 pts/0    R+   19:57   0:11 yes
docker   13039  0.0  0.0   9620   888 pts/1    R+   19:57   0:00 grep yes

When I run kill 13014, the sh process quits, and all yes processes quit as well. It's immediate, so this isn't the "TERM then wait 10s before KILL" behavior. This looks like good behavior, even though I'm using the -c flag. Am I incorrectly reproducing this?

[chriskuehl]

Hmm, that's not the behavior I see.

with setsid mode

ckuehl@sodium:~$ cat test.sh
#!/bin/sh
yes > /dev/null &
yes > /dev/null
ckuehl@sodium:~$ pgrep yes
ckuehl@sodium:~$ dumb-init ./test.sh

then, in another terminal

ckuehl@sodium:~$ pgrep yes
19179
19180
ckuehl@sodium:~$ pkill dumb-init
ckuehl@sodium:~$ pgrep yes
ckuehl@sodium:~$ 

without setsid mode

ckuehl@sodium:~$ pgrep yes
ckuehl@sodium:~$ dumb-init -c ./test.sh

in another terminal:

ckuehl@sodium:~$ pgrep yes
19241
19242
ckuehl@sodium:~$ pkill dumb-init
ckuehl@sodium:~$ pgrep yes
19241
19242

I'm running my tests outside of a Docker container, though. Are you running inside one? The container will exit when PID 1 (probably dumb-init) exits, and dumb-init exits as soon as bash exits. Since you're not in setsid mode, it won't send SIGTERM to the yes processes. But they'll be gone anyway since the entire container is about to exit.

We usually find setsid mode more useful outside of containers (e.g. being able to signal a server and its worker processes, even if it doesn't forward signals to children normally).

[joshma]

Oh derp, I'm running inside a container.

But they'll be gone anyway since the entire container is about to exit.

Could you help point me to documentation on what happens to child processes when a container exits? I was under the impression that it just sends SIGTERM + SIGKILL to PID 1, does it do anything else that causes it to differ from running it outside a container?

[lfundaro]

Why can't you have a PID 1 (dumb-init) doing setsid, i.e.: running in session mode. Is this an OS limitation or design decision ?

[loucadufault]

-c is the same as --single-child?

Edit: it is

-c, --single-child Run in single-child mode.
In this mode, signals are only proxied to the
direct child and not any of its descendants.

[husoule]

您好，您的邮件我已经收到。