krallin / tini

A tiny but valid `init` for containers
MIT License
9.83k stars 507 forks source link

Ability to set tini as the process group leader for child process #44

Open evantorrie opened 8 years ago

evantorrie commented 8 years ago

This may be a strange request, but we'd like to use tini to control a non-daemon aware process. However, we're using a container that starts up multiple services (for legacy reasons) and controls them via daemontools.

The daemontools supervisor would invoke tini, and then tini will invoke the actual process.

For security reasons, the actual service drops its privileges, but uses an "access-to-secret" system which looks at both the process user/group, as well as the process group leader's user/group to authorize access.

Currently, since tini always puts every controlled process into its own process group, this doesn't work for us.

Any suggestions? (happy to submit a pull request if you think it would make sense to add an option like this).

krallin commented 8 years ago

Hi there,

This may be a strange request, but we'd like to use tini to control a non-daemon aware process. However, we're using a container that starts up multiple services (for legacy reasons) and controls them via daemontools.

I'm not entirely sure why you need to use TIni here. Can you perhaps clarify what you mean by "control" and "non-daemon aware"?

Currently, since tini always puts every controlled process into its own process group, this doesn't work for us.

As it turns out, older versions of Tini don't wrap their children into a process group.

I think you might want to try one of those, and let me know whether it works for you and does what you need it to do.

Specifically, you should try v0.7: https://github.com/krallin/tini/releases/tag/v0.7.0, which is the latest release before process groups were added.

Any suggestions? (happy to submit a pull request if you think it would make sense to add an option like this).

Provided the above works for you, and I can better understand what this is useful for here, I'd be happy to add or merge in a flag for this.

Thanks!

evantorrie commented 8 years ago

I'm not entirely sure why you need to use TIni here. Can you perhaps clarify what you mean by "control" and "non-daemon aware"?

Yes, maybe control and non-daemon aware are the wrong terms here.

What we need is some process that will pass on signals from daemontools to its child (our process), and that collects zombies from processes that may be forked from the child. Currently our child process is an opensource piece of software that we don't want to change to put in signal handling, zombie collection etc. tini sounded reasonably well-suited to this.

The only wrinkle was the need for tini to be in the same process group as the child (and any of its children).

As it turns out, older versions of Tini don't wrap their children into a process group.

I think you might want to try one of those, and let me know whether it works for you and does what you need it to do.

Yes, let me take a look at v0.7

Also, let me know whether you think tini still makes sense for the use case mentioned here?

krallin commented 8 years ago

I'm not entirely sure why you need to use TIni here. Can you perhaps clarify what you mean by "control" and "non-daemon aware"?

Yes, maybe control and non-daemon aware are the wrong terms here.

What we need is some process that will pass on signals from daemontools to its child (our process), and that collects zombies from processes that may be forked from the child. Currently our child process is an opensource piece of software that we don't want to change to put in signal handling, zombie collection etc. tini sounded reasonably well-suited to this.

Yes; that make sense. Just make sure you run Tini in subreaper mode (-s), otherwise zombies won't be re-parented to it. If you don't add it, Tini should yell at you to do so anyway.

That being said, you could could also run Tini as the parent of daemontools (which may or may not require the subreaper flag depending on whether Tini is then PID 1.).

As it turns out, older versions of Tini don't wrap their children into a process group. I think you might want to try one of those, and let me know whether it works for you and does what you need it to do.

Yes, let me take a look at v0.7

:+1:

Also, let me know whether you think tini still makes sense for the use case mentioned here?

Yes, provided you use the subreaper flag (-s). That being said, you might want to just run Tini at the top of your process hierarchy if that's an option.

krallin commented 8 years ago

(I should mention that subreaper support only works on Linux >= 3.4)