Tini not launched as subreaper

[kumy]

Describe the bug
As used, tini is not registered as subreaper. So theorically, it doesn't works.

Error Message

 [WARN  tini (6)] Tini is not running as PID 1 and isn't registered as a child subreaper.
 Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
 To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
 time="2019-06-04T10:36:25+02:00" level=info msg="Exporter not specified. Traces won't be exported"
 2019-06-04 10:36:25.862059 I | Starting application at port :3000

To Reproduce
Nothing special, it's written in the startup logs. docker run --rm -p 3000:3000 gomods/athens:v0.4.0

Expected behavior
Tini should by default be launched as subreaper

Environment (please complete the following information):

• OS: Linux 64bit
• Go version : N/A
• Proxy version : v4.0.0
• Storage (fs/mongodb/s3 etc.) : N/A

Additional context
Adding -s to the tini options should be sufficient. It can also be configured using environment variable, but it's not default.

[kumy]

link #1155

[marwan-at-work]

@kumy I wasn't able to reproduce the error message from above:

~ docker run --rm gomods/athens:v0.4.0
time="2019-06-04T12:19:05Z" level=info msg="Exporter not specified. Traces won't be exported"
2019-06-04 12:19:05.699752 I | Starting application at port :3000

Then from another terminal:

~ docker exec -it c19f725671d2 /bin/sh
# ps -A
  PID TTY          TIME CMD
    1 ?        00:00:00 tini
    6 ?        00:00:00 athens-proxy
   24 pts/0    00:00:00 sh
   34 pts/0    00:00:00 ps

Can you tell me your Docker version, host version, and maybe anything else that can help us reproduce your scenario? Thanks!

[kumy]

Ok I've discovered what's different in our config, the docker daemon has "init": true, in it's configuration.

I'm able to reproduce on my workstation using docker run --rm -i --init gomods/athens:v0.4.0

$ sudo docker run --rm -i --init gomods/athens:v0.4.0 
[WARN  tini (6)] Tini is not running as PID 1 and isn't registered as a child subreaper.
Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
time="2019-06-04T13:37:18Z" level=info msg="Exporter not specified. Traces won't be exported"
2019-06-04 13:37:18.081821 I | Starting application at port :3000

^C$ sudo docker run --rm -i --init -e TINI_SUBREAPER=true gomods/athens:v0.4.0 
time="2019-06-04T13:39:10Z" level=info msg="Exporter not specified. Traces won't be exported"
2019-06-04 13:39:10.320030 I | Starting application at port :3000
^C$ 

[fsouza]

@kumy if you're running docker with --init you don't need tini, docker-init will do the work for you.

[kumy]

@fsouza the second tini is in the athens docker image :)

[fsouza]

@kumy yeah, sorry my bad x) What I meant is that since you're using --init you could change the entrypoint to be just /bin/athens-proxy.

@marwan-at-work there's a hacky alternative: introduce a custom entrypoint that checks the PID and only uses tini if it's 1 x)

[marwan-at-work]

@kumy so if you are running with init=true, that means tini will not be reaping anything, but shouldn't that also mean that Docker will be reaping the defunct processes? In other words, can we just ignore the warning message?

[marwan-at-work]

@fsouza

there's a hacky alternative: introduce a custom entrypoint that checks the PID and only uses tini if it's 1 x)

if the above true, maybe ignoring the the warning message is better than the hack?

A third option is to include the -s flag no matter what?

[marwan-at-work]

Also as you said, maybe changing the ENTRYPOINT on the fly (if a user is aware of their init configuration) is also not a bad alternative?

[kumy]

@kumy yeah, sorry my bad x) What I meant is that since you're using --init you could change the entrypoint to be just /bin/athens-proxy.

I've added it for the demo so it can be reproduced by everyone (I've found this option originally in our production swarm cluster).

if you are running with init=true, that means tini will not be reaping anything, but shouldn't that also mean that Docker will be reaping the defunct processes?

if the athens container didn't included tiny, then the "docker daemon" would have reaped the zombies.

I've workaround it on our production, by adding TINI_SUBREAPER: "true". then no warning at all, and tini from the container is reaping processes

[marpio]

@kumy

if the athens container didn't included tiny, then the "docker daemon" would have reap the zombies.

Are you saying that the "docker tini" would not reap the zombie procs?
I would assume that, since the docker-tini is running as PID 1 it would do that anyway, regardless of the second "athens tini".

[kumy]

@marpio You are certainly right!

It seems this issue is really specific to configuration on our side, and there are plenty of workaround available. Feel free to close as is if you wish.

[marpio]

@kumy @marwan-at-work do you think adding some documentation would be enough?

[marwan-at-work]

Yes, that'd be great.