Closed mheon closed 6 years ago
Docker seems to act the same way, so this could be expected behavior.
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.
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.
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.
@mheon If you can get this to work with docker, we can reopen.
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?
@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.
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.
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?
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
.
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..
Right bash within fedora is ignoring the signal, while sh within busybox exits.
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..
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.
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