Please provide smaller static linked binaries (eg. using musl) about tini HOT 9 CLOSED

I think it should be fine - glibc's behavior is a bit unintuitive here. For example, if you run:

tini program -v

Then -v is interpreted as an option for tini, whereas you probably meant for it to be interpreted by program instead.

Likewise, if the option does NOT exist for tini, then it'll throw an error. For example:

tini program -x

This will fail because -x is not a valid flag for Tini.

This is why in the README I'm encouraging using tini -- program, which fixes this. It seems muslc accepts this as well (but that flag doesn't do anything there). I'll double-check whether the "posixly-correct" argument parsing for glibc breaks anything, and if not I'll plan to add the + modifier to make this Tini's standard behavior.

from tini.

The required dependencies can be installed with

apt-get install musl-tools

from tini.

Yeah, this sounds like a good idea; thank you!

One concern I have is that glibc and muslc parse command line arguments a little differently. glibc does the following, but muslc does not:

By default, getopt() permutes the contents of argv as it scans, so that eventually all the nonoptions are at the end. Two other modes are also implemented. If the first character of optstring is '+' or the environment variable POSIXLY_CORRECT is set, then option processing stops as soon as a nonoption argument is encountered. If the first character of optstring is '-', then each nonoption argv-element is handled as if it were the argument of an option with character code 1. (This is used by programs that were written to expect options and other argv-elements in any order and that care about the ordering of the two.) The special argument "--" forces an end of option-scanning regardless of the scanning mode.

I'm leaning towards forcing the "posixly correct" mode, which is probably what users expect anyway (that's also how e.g. docker run works, so users in this ecosystem should be familiar with it).

Anyhow, work in progress here: #92

from tini.

Would be interesting how tini currently behaves in alpine linux, as it is compiled against musl there.

For the build file:
https://git.alpinelinux.org/cgit/aports/tree/community/tini/APKBUILD

from tini.

Just curious, what's your use case here where you need such small tini?

from tini.

We have a policy of not creating docker containers without init as soon as we can not guarantee the daemon does not fork during it's lifetime.

We are currently experimenting to build our containers with bazel thus i needed a small statically compiled init there (to have a common init base layer for static go executables AND normal dynamically compiled excutables).
And as eg. a debian based redis container is only 13MB in size, if build with bazel, wasting 1MB for tini just seems wrong for a kubernetes cluster where the init layer is running thousand of times.

from tini.

@gebi I released v0.15.0 today, which now includes musl-based builds! The binaries will be available once the build completes: https://travis-ci.org/krallin/tini/builds/249743590

from tini.

yay, thx :)!
already updated our containers, works perfectly!

from tini.

Happy to hear it 😄

from tini.