Andrew Dunstan <and...@dunslane.net> writes:
> On 5/3/21 5:13 PM, Dagfinn Ilmari Mannsåker wrote:
>> Given that a number of minimal `init`s already exist specifically for
>> the case of running a single application in a container, I don't think
>> Postgres should to reinvent that wheel. A quick eyball of the output of
>> `apt search container init` on a Debian Bullseyse system reveals at
>> least four:
>>
>> - https://github.com/Yelp/dumb-init
>> - https://github.com/krallin/tini
>> - https://github.com/fpco/pid1
>> - https://github.com/openSUSE/catatonit
>>
>> The first one also explains why there's more to being PID 1 than just
>> handling reparented children.
> I looked at the first of these, and it seems perfectly sensible. So I
> agree all we really need to do is refuse to run as PID 1.
[ for the archives' sake ] I looked at the documentation for dumb-init,
and it claims there are basically two things weird about init:
1. The kernel applies different signal handling rules to it.
2. It has to reap children it didn't spawn.
Whether that list is exhaustive, I dunno ... it has an odor of
Linux-specificity to me. Anyway, #2 is clearly no problem for
the postmaster, since it's doing that anyway; quibbles about
whether it *should* do that without complaining aside. We could
imagine trying to handle #1, but that seems like the sort of dank
system-specific corner that we'd regret having got into. If the
behavior for init isn't consistent with our needs, or changes
across platforms or kernel versions, things could get very messy
indeed. I'm still thinking that we're best off refusing to do
that and making people install one of these shims that's meant
for the job.
regards, tom lane
