tini flags and --

[crosbymichael]

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?

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.

Thanks!

[krallin]

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 runs foo.
• If you run tini foo -v, then Tini runs foo -v.
• Finally, if you tini -v foo bar -qux, then Tini reads the -v flag, then runs foo 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,

[crosbymichael]

@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.

[krallin]

@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,

[crosbymichael]

Let me check that we have cmake in our buildchain but I don't think it will be an issue.

[crosbymichael]

We currently don't have cmake but I'll add it to our builds so that works for me.

[krallin]

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 for strings — more conversation in here: Include license in strings #46), for some reason, this is usually included in a vim-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!

[crosbymichael]

@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.

[krallin]

Sounds great; thanks @crosbymichael!

[crosbymichael]

I opened the docker pr here moby/moby#28037

[krallin]

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!

[crosbymichael]

@krallin ahh yes, i'm sure @mlaventure would greatly appreciate that

[mlaventure]

yes, I would very much like to have --version working so we can ascertain what version is actually used, thanks! :)

[krallin]

Sure; how's this @mlaventure @crosbymichael: #58?

[glensc]

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

[crosbymichael]

@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.

[glensc]

@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...)

[glensc]

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)