Comments (17)
Hey @crosbymichael, thanks for reaching out!
Because tini has flags the ability to inject init as the init in many containers is not possible without having to change the container. Is there a way that we can remove these options so that this can be a drop in replacement as a container init for something like Docker?
Would it make sense if Tini behaved like Docker itself does in docker run
, and ignored any flags found after the program (image in Docker's case) it's meant to run? For example:
- If you run
tini -v foo
, then Tini reads the-v
flag, and runsfoo
. - If you run
tini foo -v
, then Tini runsfoo -v
. - Finally, if you
tini -v foo bar -qux
, then Tini reads the-v
flag, then runsfoo bar -qux
.
Now, obviously, this won't work if the command to run collides with a Tini flag. This is arguably pretty unlikely, but is it an acceptable tradeoff here?
Note that this would be a very trivial change in Tini (one I should be doing anyway, since right now it means Tini otherwise behaves differently depending on the libc it was compiled with: musl already implements the behavior I'm describing above); I'd just need to add +
in front of the opt strings π
(One upside of this approach is that curious folks could run /dev/init -h
to get an idea of what this thing is)
Another (perhaps safer) solution would be to look at whether /proc/self/exe
points to /dev/init
and disable option processing altogether in this case. Whether or not this is a good idea probably depends on whether you plan on /dev/init
being an implementation detail or not. Let me know!
(One downside of this approach is that /dev/init -h
would try to run -h
and fail)
Finally, one last (perhaps the simplest) option is of course a compile flag to disable option processing altogerher. I'm not sure how you'd plan to distribute Tini as a container init for Docker, so this may or may not be a good option. But let me know! (under this option, /dev/init -h
wouldn't work, of course)
Also would you be interested in having tini the default init for container containers provided by the daemon? I wrote a very similar thing and instead of having two inits I'm interested in using tini instead but the requirement for
--
is a deal breaker at the moment and would require changes for what we want to do.
I would, naturally; I'm very flattered that you're considering Tini for this! π
(though I must say I'm also a little surprised having followed moby/moby#26061 π)
I'm happy to make any of all 3 suggestions I listed above. Let me know if any of these are acceptable for Docker's purposes!
Cheers,
from tini.
@krallin thanks and sorry that you were surprised following the PR, I didn't look into this project until after I started working on that PR but now there is no need to duplicate efforts and this project is built very well.
We would be distributing tini in the docker packages so we would also be compiling it inside our build process. I think a flag to disable tini flag parsing would work best for us as its an easy option and we are not abusing flag parsing.
With the large number of applications that are run, flag collisions can happen often especially with the -v, -h flags.
from tini.
@krallin thanks and sorry that you were surprised following the PR, I didn't look into this project until after I started working on that PR but now there is no need to duplicate efforts and this project is built very well.
Ha, no worries at all; I think I was a little unclear here: I actually meant that I was a little surprised by this issue, not by the Docker PR. Sorry about the confusion!
We would be distributing tini in the docker packages so we would also be compiling it inside our build process. I think a flag to disable tini flag parsing would work best for us as its an easy option and we are not abusing flag parsing.
Sounds great! I'll get that in shortly (480fed1 - most of the changes there are for CI, though).
I'm using cmake
, so you'd want to do something along the lines of:
cmake -B"${BUILD_DIR}" -H"${SOURCE_DIR}" -DNO_ARGS=ON
Does that work?
(if using cmake is a problem, you could compile Tini compiler directly, but if so let me know, there are a couple things I could do to make the build process simpler without Cmake)
Cheers,
from tini.
Let me check that we have cmake in our buildchain but I don't think it will be an issue.
from tini.
We currently don't have cmake
but I'll add it to our builds so that works for me.
from tini.
Hey @crosbymichael, I just released Tini 0.11.0, which includes the new flag.
A couple notes summarizing the build:
- The build uses
xxd
to inject the license file into the binary (to expose via a-l
flag... but also forstrings
β more conversation in here: #46), for some reason, this is usually included in avim-common
package or some such. - You can access the new "no flags" compile option via:
cmake -DNO_ARGS=ON
I should mention that I left in ENV var parsing (since these are prefixed with TINI_
) even when the option is set, but I'm happy to ifdef that out too if needed (there's only one: TINI_SUBREAPER
).
Finally, if that's useful as a reference, here are the package files for a couple distros that have packaged Tini:
- https://github.com/alpinelinux/aports/blob/307254b198498e167120d4ec9ce9d72856f5a182/community/tini/APKBUILD
- https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/tini/tini-0.10.0.ebuild?id=4368fc6b0eab5b636d500cc256581c06b1ce39f6
Thanks again!
from tini.
@krallin thanks. The env stuff seems ok to me since it has the TINI_
prefix.
Thanks and i'll try integrating your 0.11.0 release and ping you on the docker PR.
from tini.
Sounds great; thanks @crosbymichael!
from tini.
I opened the docker pr here moby/moby#28037
from tini.
Awesome; thanks @crosbymichael! π
As an aside, I noticed moby/moby#27955 might require a way to extract the version from the resulting binary (which won't work when Tini consumes no args at all). I'm happy to make some tweaks to accommodate this (perhaps by consuming --version
if it's the only argument; or via an ENV var); just let me know if that's indeed needed!
from tini.
@krallin ahh yes, i'm sure @mlaventure would greatly appreciate that
from tini.
yes, I would very much like to have --version
working so we can ascertain what version is actually used, thanks! :)
from tini.
Sure; how's this @mlaventure @crosbymichael: #58?
from tini.
if the sole reason for -DMINIMAL=ON
was this PR, why not actually implement --
argument? this way i can package in distro version of tini
which docker
can just use instead of having custom builds of tini
.
/sbin/tini --tiny-arg -- command --command-args
it's pretty standard to stop command line args parsing on --
, maybe it's even in C library
from tini.
@glensc it is implemented but we want to inject an init in every container (if you have this feature turned on) without everyone having to rewrite their dockerfiles to add --
to their ENTRYPOINT or CMD.
from tini.
@crosbymichael i mean dockerd mounts /dev/init
and executes /dev/init original-entrypoint
requiring custom build of tini.
but i do not see why can't dockerd execute:
/dev/init -- original-entrypoint
as for shell in CMD "echo 123"
it would execute:
/dev/init -- sh -c 'echo "123"'
i.e in the actual code:
s.Process.Args = append([]string{"/dev/init", "--", c.Path}, c.Args...)
from tini.
the patch just works, should i send PR to docker/docker?
host# docker run --init --rm -it glen/pld bash -l
bash-4.4# ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Nov 15 03:33 /proc/1/exe -> /dev/init
bash-4.4# /dev/init -- sh -c 'echo "kala" "maja"; cat /proc/$$/cmdline|tr "\0" "\n">cmdline'
[WARN tini (39)] 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.
kala maja
bash-4.4# cat cmdline
sh
-c
echo "kala" "maja"; cat /proc/$$/cmdline|tr "\0" "\n">cmdline
bash-4.4#
--- docker-1.13.0-rc1/daemon/oci_linux.go~ 2016-11-11 12:27:33.000000000 +0200
+++ docker-1.13.0-rc1/daemon/oci_linux.go 2016-11-15 02:42:25.660635864 +0200
@@ -593,7 +593,7 @@
if c.HostConfig.PidMode.IsPrivate() {
if (c.HostConfig.Init != nil && *c.HostConfig.Init) ||
(c.HostConfig.Init == nil && daemon.configStore.Init) {
- s.Process.Args = append([]string{"/dev/init", c.Path}, c.Args...)
+ s.Process.Args = append([]string{"/dev/init", "--", c.Path}, c.Args...)
var path string
if daemon.configStore.InitPath == "" && c.HostConfig.InitPath == "" {
path, err = exec.LookPath(DefaultInitBinary)
from tini.
Related Issues (20)
- Forward env vars HOT 3
- How come tini proxies signals to child processes if the sigcgt bits are all 0? HOT 1
- CentOS 7 - tini version detected as malware HOT 5
- SIGTERM not working with exec command in the entrypoint script HOT 4
- ownership of /proc/1/* is root even the user is non-root HOT 3
- Support setuid and setguid before execute command?
- Supress TRACE but show DEBUG HOT 1
- Event not generated when File change happens HOT 1
- About Tini version planningοΌ HOT 2
- aarch64 version available? HOT 3
- Non-terminal signals are killing containers running with --init flag HOT 3
- stack-protector not work HOT 4
- [FATAL tini (7)] exec bash failed: No such file or directory HOT 3
- [CVE-2023-25139]tini-static executable seems vulnerable HOT 1
- example / explanation HOT 1
- How can I confirm that tini is running? HOT 1
- prctl(PR_SET_PDEATHSIG, ...) should be called after fork(), not before HOT 4
- MI6&termux&clang-16 build failed HOT 2
- Using "docker run --init" with arguments to tini HOT 2
- tini docker windows container HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tini.