Re: PG in container w/ pid namespace is init, process exits cause restart - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: PG in container w/ pid namespace is init, process exits cause restart
Date
Msg-id 40db88e6-cff4-5b19-ceef-c28157ba4ccf@dunslane.net
Whole thread Raw
In response to Re: PG in container w/ pid namespace is init, process exits cause restart  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Responses Re: PG in container w/ pid namespace is init, process exits cause restart
List pgsql-hackers
On 5/3/21 5:13 PM, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
>
>> Maybe we should put in a startup-time check, analogous to the
>> can't-run-as-root test, that the postmaster mustn't be PID 1.
> 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.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Tom Lane
Date:
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart