Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-terminal signals are killing containers running with --init flag #204

Closed
rayrapetyan opened this issue Dec 7, 2022 · 3 comments
Closed

Comments

@rayrapetyan
Copy link

Description
This looks like invalid behavior: docker-init (tini) process should proxy signals to child processes.
Instead any container started with --init flag can be killed with a non-terminal signal (e.g. SIGUSR2, SIGHUP etc).

Reproduce

  1. docker run --init --rm -it -p 80:80 --name hello strm/helloworld-http
  2. docker kill --signal SIGUSR2 hello

Expected behavior
Container continues to run (as it does when started without --init flag)

Actual
Container is being stopped and killed

docker version

Client: Docker Engine - Community
 Version:           20.10.21
 API version:       1.41
 Go version:        go1.18.7
 Git commit:        baeda1f
 Built:             Tue Oct 25 18:02:28 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.21
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.7
  Git commit:       3056208
  Built:            Tue Oct 25 18:00:19 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.10
  GitCommit:        770bd0108c32f3fb5c73ae1264f7e503fe7b2661
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.12.2)
  scan: Docker Scan (Docker Inc., v0.21.0)

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 32
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.0-19-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.14GiB
 Name: ara-home-pc-debian
 ID: 3KXM:A6UU:LLYL:UYPH:ZWH2:AJ37:G5UL:2UZC:653T:BFLZ:R5OD:DOSR
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
@tianon
Copy link
Contributor

tianon commented Dec 7, 2022

I think this means your process doesn't have a handler for SIGUSR2 registered; from signal(7) (https://manpages.debian.org/bullseye/manpages/signal.7.en.html#Standard_signals), SIGUSR2 is a terminating signal by default.

@rayrapetyan
Copy link
Author

Hm, I didn't know SIGUSRs are terminating by default, that's why used a random web server as example, sorry. But initially this issue happened with my own image which has a SIGUSR2 handler. I've created a POC repo: https://github.com/rayrapetyan/test_sig.

Steps to reproduce the issue:

  1. Run cmd.sh locally
  2. See output:
PID of this script: 433226
Running....
Running....
...
  1. Send SIGUSR2 signal: kill -SIGUSR2 433226
  2. Notice signal was intercepted in cmd.sh:
handling SIGUSR2
Running....

and process continues running as expected.

Now run cmd.sh from container:

docker build -t test_sig:latest .
docker run --rm --init --name test_sig test_sig:latest

Send SIGUSR2:
docker kill --signal SIGUSR2 test_sig

Expected: cmd.sh running inside a docker container should receive and handle a signal and continue running.
Actual: container stops.

Now after looking into how cmd.sh is running inside a container:
/sbin/docker-init -- /bin/sh -c ./cmd.sh -> bash cmd.sh
I realize that because of /bin/sh is running before bash, it's intercepting all signals and doesn't forward them to a child processes (bash) properly?

@rayrapetyan
Copy link
Author

Works when running as:
docker run --rm --init --name test_sig test_sig:latest ./cmd.sh
so no /bin/sh in between.

@rayrapetyan rayrapetyan closed this as not planned Won't fix, can't repro, duplicate, stale Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants