Re: PG in container w/ pid namespace is init, process exits cause restart

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart
Date: 2021-05-04 19:57:39
Message-ID: 40db88e6-cff4-5b19-ceef-c28157ba4ccf@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 5/3/21 5:13 PM, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-04 20:35:39 Re: PG in container w/ pid namespace is init, process exits cause restart
Previous Message Tom Lane 2021-05-04 19:47:41 Re: WIP: WAL prefetch (another approach)