Foward signals to all child (and adopted) processes

[johnmarcou]

Hi,

Thank you for tini !

During my tests with Docker, I noticed tini:

• starts the process given as the argument as the "first child"
• forwards received signals to the "first child" only (or the sub-process branch if -g is used)
• returns the exit code of the "first child"

In the case where some process has been orphaned and adopted by tini, is it possible to make tini forward signals to these running child processes as well ?

I noticed on an Ubuntu VM, that traditional init seems to ask "all remaining processes to terminate" by sending SIGTERM. I'd like to reproduce this behaviour in order to gracefully stop every child process, even adopted ones.

Thank you for your help.

[krallin]

I'm not certain this would be as useful as you'd hope. Tini won't wait for those other processes to exit anyway, so it's already pretty far from traditional init.

Can you expand a little bit on your use case here? If you need advanced init functionality, it's possible Tini may not be the right choice you.

[johnmarcou]

Thank you for your reply.

For a specific usage, we need to start graphical environment in a Docker container. Let’s consider an opened graphical mate-terminal with a bash session executing an app (let’s say a sleeping app which waits 3 sec after receiving a SIGTERM then touch a file when it’s properly close).

When you docker stop [container], what I understood so far is:

• dockerd sends SIGTERM to tini
• tini sends SIGTERM to supervisord
• supervirsord sends SIGTERM to mate-session
• mate-session sends SIGTERM to mate-terminal
• mate-terminal sends a SIGHUP to the app
• app receives signal and is about to terminates... (sleeping 3 sec, doing some cleaning stuff, but taking long time)
• mate-session terminates
• app is detached but still running as orphans process. It is adopted by tini.
• other supervisord processes are finally terminated
• supervisord terminates
• as PID 1, init terminates
• docker cleans the container namespace
• app receives a SIGKILL

In this scenario, if we set a a “sleeping 5sec” subprocess for supervisord to add latency, the app has the time to terminate properly and touch the file. :+1:

We tried this scenario in a traditional Ubuntu machine, before halting the system, the init process does an “asking all remaining processes to terminate” action, which SIGTERM all child processes and SIGKILL them after 10 sec.

Is it the expected behavior of tini or did we miss an option or something ? Do you suggest another process manager or PID 1 init manager ?

[pvanderlinden]

I came across the same problem. In my quick tests https://github.com/fpco/pid1 works better with this. The scenario I have been testing is running an executable from a bash script (something I see quiet often), which listens to term signals and does a cleanup + exit. With pid1 you will see the executable have the time for a gracefull shutdown, with tini the executable won't have the time.

[krallin]

@johnmarcou ,

Is it the expected behavior of tini or did we miss an option or something ?

This is indeed the expected behavior, yes.

Tini is designed to be an init for containers, where the best practice is to run single-process systems.

If you want a more traditional init system, then Tini is probably not what you're looking for (supporting desktop environment like Mate is definitely out of scope for Tini).

Do you suggest another process manager or PID 1 init manager ?

If what you need is a traditional init system, I would suggest using one 😄

I believe you can actually run Upstart in a Docker container (Upstart used to be Ubuntu's default init system), and it looks like you could even run systemd there (systemd being Ubuntu's current init system).

That said, it sounds like @pvanderlinden has a lighter-weight suggestion for you: pid1. I can't say I have any direct experience with it, though.

[lmb]

I think this would be useful to run double forking processes under tini. Seems like tini exits as soon as the first child dies at the moment.

It would be great if there were a flag where tini would wait for all children to exit, and return the first non-zero exit code. Combined with -g this might be a neat solution, and would allow more esoteric daemons to run under it.

[ebikt]

@lmb forking (and double forking) is evil in this context. Prevent it whenever you can. If you can't, then you need specific behavior for specific case, because the process may launch several small programs (utilities) to get some info about system and then do the double-fork. Those utilities may also fork, without waiting for their children, because init should do this.

[mitar]

I made another init system for Docker, dinit, which tries to address exactly this: having multiple children processes, sending signal to them when the container (PID 1) gets the signal, and then waiting for all to finish. If some process does not finish, then it is left to the container's supervisor (i.e., Docker) to kill all processes.

[krallin]

Thanks for sharing, congrats on releasing, it’s always good to have options for folks that would like a fuller-featured init system in their containers :)

On Fri, 14 Jul 2023 at 15:20, Mitar @.***> wrote:

I made another init system for Docker, dinit https://gitlab.com/tozd/dinit, which tries to address exactly this: having multiple children processes, sending signal to them when the container (PID 1) gets the signal, and then waiting for all to finish. If some process does not finish, then it is left to the container's supervisor (i.e., Docker) to kill all processes.

— Reply to this email directly, view it on GitHub https://github.com/krallin/tini/issues/95#issuecomment-1635856904, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANIHVRDXVYY74EIMVMIBXDXQFBQDANCNFSM4DR43XIA . You are receiving this because you commented.Message ID: @.***>