Обсуждение: [GENERAL] Please say it isn't so

Hi all,

Please tell me this is a mistake:

https://wiki.postgresql.org/wiki/Systemd

Why a database system should care about how processes get started is
beyond me. Systemd is an entangled mess that every year subsumes more
and more of the operating system, in a very non-cooperative way.

There are almost ten init systems. In every one of those init systems,
one can run a process supervisor, such as runit or s6 or
daemontools-encore, completely capable of starting the postgres server.

Every year, systemd further hinders interoperability, further erodes
interchangeability of parts, and continues to address problems with
WONTFIX. In the long run, you do your users no favor by including
init-system specific code in Postgres or its makefiles. If systemd
can't correctly start Postgres, I guarantee you that s6 or runit,
running on top of systemd, can.

Postgres doesn't care which language makes a query to it. Why
should Postgres care which init system started it? I hope you can free
Postgres of init-specific code, and if for some reason you can't do
that, at least don't recommend init-specific code.

Thanks,

SteveT

Steve Litt
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz

On 12/07/17 05:00, Steve Litt wrote:
> Hi all,
>
> Please tell me this is a mistake:
>
> https://wiki.postgresql.org/wiki/Systemd
>
> Why a database system should care about how processes get started is
> beyond me. Systemd is an entangled mess that every year subsumes more
> and more of the operating system, in a very non-cooperative way.
>
> There are almost ten init systems. In every one of those init systems,
> one can run a process supervisor, such as runit or s6 or
> daemontools-encore, completely capable of starting the postgres server.
>
> Every year, systemd further hinders interoperability, further erodes
> interchangeability of parts, and continues to address problems with
> WONTFIX. In the long run, you do your users no favor by including
> init-system specific code in Postgres or its makefiles. If systemd
> can't correctly start Postgres, I guarantee you that s6 or runit,
> running on top of systemd, can.
>
> Postgres doesn't care which language makes a query to it. Why
> should Postgres care which init system started it? I hope you can free
> Postgres of init-specific code, and if for some reason you can't do
> that, at least don't recommend init-specific code.

OTOH since systemd is what's being supported by a significant number of
distributions it makes sense to at least try to work robustly with it.

While my preference would have been to have made such a change at a
major version transition, the reality is that database systems are
competitive, and not keeping up with the underlying platform would have
been very much to PostgreSQL's disadvantage,

OP: Please note that you do yourself no favours at all by posting a
subject line which could very easily be misinterpreted as spam.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

On 12 July 2017 at 00:51, Steve Litt <slitt@troubleshooters.com> wrote:
> Hi all,
>
> Please tell me this is a mistake:
>
> https://wiki.postgresql.org/wiki/Systemd
>
> Why a database system should care about how processes get started is
> beyond me. Systemd is an entangled mess that every year subsumes more
> and more of the operating system, in a very non-cooperative way.
>
> There are almost ten init systems. In every one of those init systems,
> one can run a process supervisor, such as runit or s6 or
> daemontools-encore, completely capable of starting the postgres server.
>
> Every year, systemd further hinders interoperability, further erodes
> interchangeability of parts, and continues to address problems with
> WONTFIX. In the long run, you do your users no favor by including
> init-system specific code in Postgres or its makefiles. If systemd
> can't correctly start Postgres, I guarantee you that s6 or runit,
> running on top of systemd, can.
>
> Postgres doesn't care which language makes a query to it. Why
> should Postgres care which init system started it? I hope you can free
> Postgres of init-specific code, and if for some reason you can't do
> that, at least don't recommend init-specific code.

I'm did a bit of review work on the relevant change, once upon a time...

The change was not to "make PostgreSQL forcibly dependent on
SystemD"; since PostgreSQL is expected to run properly on systems
that SystemD does not support, it should be obvious that to do
that would be horribly inappropriate.  Only an [insert insult here]
would suggest that, right???

What was added was entirely *optional*.

On systems where one is using SystemD, PostgreSQL can do a
couple of bits of integration that actually are somewhat useful.

a) At startup, PostgreSQL will notify SystemD when it is completed
with startup processes (e.g. - the recovery that may take extra
time if you had an unclean shutdown).

This is useful in that it means SystemD knows when PostgreSQL
is actually ready to accept user access.

It can defer startup of dependent services.

That dependency management is Actually Useful, and is one of the
things that is useful about having something smarter than Good Old
SysVInit.  It means that if you had an unclean system shutdown,
meaning that it takes longer for PostgreSQL to start up on the next
boot, this doesn't lead to a cascade of service failures.

I'm not particularly thrilled with SystemD; it has a habit of making
its scope creep.  But the above was one of the legitimate cases
where "a better init" is actually fairly desirable, where traditional
sysV init was pretty creaky.

b) There's some "manage logs using SystemD's logging"
integration.

I'm not as "gruntled" about that, but if someone wants to centralize
their logging, that's their choice, and it's a reasonable thing to desire.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Vick Khera <vivek@khera.org> writes:
> What exactly does the configure flag to enable systemd support do?

Not a lot.  A quick grep for USE_SYSTEMD says it does nothing except
add code in the postmaster to report ready/not-ready state transitions
by calling sd_notify().  We have significantly more lines of
documentation concerning systemd than we do code.

            regards, tom lane