Open evantorrie opened 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!
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?
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.
(I should mention that subreaper support only works on Linux >= 3.4)
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).