Processes in container can't catch SIGTERM

[mheon]

Reproducer:

kpod run -t -i --rm fedora:27 bash In the container: trap "echo Got SIGTERM" 15 Outside the container: kpod kill $CONTAINER_ID

Expected behavior: the container prints "Got SIGTERM" Actual behavior: the container exits, having not caught SIGTERM

[mheon]

Docker seems to act the same way, so this could be expected behavior.

[rhatdan]

Maybe you can only catch a signal from a process inside of your namespace. Try nsenter into the pid namepsace and then send a kill signal. And see if it is caught.

[mheon]

You can definitely catch signals from 'kpod kill' - I tried with various others. SIGKILL and SIGSTOP can't be caught, but you should be able to catch all the others, including SIGTERM. I did a lot of testing on signals in Docker a few years ago, and it could definitely be caught then.

[rhatdan]

I did the exact test for docker that I did for podman and they both exited the same way.

docker run -ti fedora sh
#  trap "echo Got SIGTERM" 15
# exit

This is just using the kill -s 15 $PID

podman run -ti fedora sh
#  trap "echo Got SIGTERM" 15
# exit

Sending pid 1 inside of the container worked correctly. Seems like a process that is in a different pid namespace can not catch signals from its parent pid namespace.

[rhatdan]

@mheon If you can get this to work with docker, we can reopen.

[bam80]

Hmm, even withing container, it seems INT can't be caught - you can't interrupt read with ^C in following example:

$ podman run -ti fedora sh -c "read -p 'Press a key...' && echo OK"
Press a key...^C^C^C^C^C

Ideas?

[vrothberg]

@bam80, you need to run it with --init. This will set an init binary as the entrypoint of the container which will be able to do proper signal handling.

[mheon]

That should work without init, though, assuming --sig-proxy is active (and it is by default). We'll forward the SIGINT from the Podman process in the foreground to the container's PID1.

[bam80]

That should work without init, though, assuming --sig-proxy is active

Well, it doesn't work without the --init:

$ podman run -ti --rm --sig-proxy fedora bash -c "read -p 'Press a key...' && echo OK"
Press a key...^C^C

Bug?

[vrothberg]

I don't think it's a bug. Without --init we are limited by how PID 1 inside the container behaves with respect to signal handling. In some cases it may work, in others it won't.

Running the same with busybox, for instance, works: $ podman run -ti --rm busybox sh -c "read -p 'Press a key...' && echo OK"

Hence, if signal handling is critical, we should always use --init.

[bam80]

Running the same with busybox, for instance, works

Indeed. Probably in this case PID 1 is busybox itself, and it handles signals differently than PID 1 of other containers we tried before..

[rhatdan]

Right bash within fedora is ignoring the signal, while sh within busybox exits.

[bam80]

One more question here: I've made a wrapper around cmake to use it inside Qt Creator:

$ cat cmake
#!/bin/bash
exec podman exec -it sdk_toolchain_1 cmake $@

For some reason, if I skip either of -i or -t, I can't stop that "cmake" from Qt Creator, so it runs until it finishes itself. Any ideas why? -it is somewhat problematic here because for some other reason it pollutes output and Qt Creator doesn't capable to parse Ninja's stats for it's progress bar any more..

[rhatdan]

The -i tells the Podman to setup input to go to the process within the container, and -t tells it to setup a tty, I am not fully sure why they are needed.

You could attempt to redirect stdout and stderr to /dev/null, which might help you. @edsantiago Might have better information.