Add hint about Perl5 as PID 1 in the docs

[zakame]

Thanks @diocles for the blog post.

I should probably add a hint for it in https://github.com/docker-library/docs/blob/master/perl/content.md for everyone's future reference, namely to run the container on Docker >= 1.13 with --init flag if they need it (or using dumb-init on older Docker versions.)

[tianon]

Just to add, tini (https://github.com/krallin/tini) is the implementation behind --init (docker-init on your local system which gets bind-mounted to /dev/init in the container when using --init is a compiled copy of tini), and has a larger number of official release binary architectures than dumb-init does: https://github.com/krallin/tini/releases/tag/v0.16.1

[mohawk2]

I believe this is only an issue when using CMD in one's image in shell form, not JSON form (since it's the Bash that has the problem, and JSON form doesn't use it).

[mephinet]

mohawk2: no, this is also the case when running without bash, because perl itself doesn't handle signals the way it should when running as PID1 - see the OPs blog post link.

While --init is a solution for users of pure docker, it does not help users of orchestrations like kubernetes, as there is no possibility at present to achieve something comparable to --init.
Therefore, I propose to add tini or dumb-init to the Perl docker image, and specify it as ENTRYPOINT. This saves all users of the signal handling and process reaping issues. This can be achieved by adding these two lines to all Dockerfiles:

RUN apt-get update && apt-get install -y dumb-init && apt-get clean && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["dumb-init"]

After this change, the example $ docker run myperl:5 perl -E 'sleep 300' can be Ctrl-C'ed.

[zakame]

Having run into this issue again from a different way (CircleCI testing) I'm now inclined to add @mephinet's suggestion by default. It should not affect the current CMD setting we have and should be least the astonishing to users expecting signal handling in Perl to Just Work™.

Installing the dumb-init package seems the best option as that is present on both Stretch and Buster, but later we can probably move to tini.

[zakame]

Forgot to consider Jessie for the older perls (which does not have both dumb-init or tini packages) so building from source seems the next best option; tini would be preferable in that case. We can also get tini straight off of GitHub releases but since it is small enough (with no other dependency than libc and cmake,) I think we can afford spending a bit more time building it right after the perl build.

[zakame]

Erring on the side of caution for now and document the current PID 1 behavior first; while my testing of using tini as default ENTRYPOINT seems to yield no issues across different Perl versions and architectures, it might be better to hold that back for a while until more people are aware and ask about it becoming the default.

[mohawk2]

Is there a channel to loudly announce the intention? This is a change intended to reduce surprise, rather than to add features.

[zakame]

I became first aware of this issue through a blog, so maybe I can just make a post of my own on blogs.perl.org for this. Might also bring it up further to p5p...