Since we're ignoring SIGTTOU (for good reason), our log messages
could show in another program's output. To make the life of users
easier, let's clarify that the messages are owned by Tini.
In the rare scenario where Tini is not running as PID 1 and its
child (or something else) sets TOSTOP on the tty, then Tini would
hang when if it tries to write debug messages. This commit fixes
this problem by ignoring SIGTTOU.
In the also rare scenario where two Tini instances are running, the
tty-passing could end up being done improperly (if the parent Tini
instance passes the tty to the child before the grandparent Tini
instance passes it to the parent Tini instance), and result in the
parent Tini instance running in the foreground. This commit fixes
this problem by passing the tty in the child (which we can do
because we are ignoring SIGTTOU).
tini only kills the immediate child process. This means that if you
do, for example,
docker run krallin/ubuntu-tini sh -c 'sleep 10'
and ctrl-C it, nothing happens: SIGINT is sent to the 'sh' process,
but that shell won't react to it while it is waiting for the 'sleep'
to finish.
This change adds a -g option to put the child process of tini into a
new process group, and sends signals to that group, so that every
process in the group gets a signal. This corresponds more closely to
what happens when you do ctrl-C etc. in a terminal: The signal is sent
to the foreground process group.
So if you try the example above with a container image that passes -g
to tini, the SIGINT will be received by the 'sleep', and the container
promptly exits.
Using the child subreaper mechanism, we can actually run
tests inside the CI environment without depending on Docker.
While this does not replace the existing tests, it allows
at least some functional coverage within CI.
Valgrind does like statically-linked binaries due to false positives
coming from libc, which are ignord only if Valgrind can tell they're in
libc (which isn't the case when using static linking).
This allows the use of `tini` within even more minimal environments (such as images that are `FROM scratch` with a single application binary `COPY`'d in).
On Travis, Cmake does not run from the same directory as in our local
build environment. We need to ensure that PATH contains absolute paths
so that Cmake can find our stub rpmbuild.
Travis uses Ubuntu Precise, which has CMake 3.8. That version does not
have support for excluding /usr and /usr/bin from the %files% list
(which results in a package that conflicts with the filesystem package
and fails to install).
This commit:
+ Builds on Precise instead of Trusty
+ Adds install tests