Обсуждение: [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 Tue, Jul 11, 2017 at 9:51 PM, 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.
Take a deep breath...
You are looking at a page about PostgreSQL with specifics surrounding installation on a machine running systemd. In that case it is naturally recommended to compile using the --with-systemd option to better integrate with systemd.
As the docs about that option say, "...This improves integration if the server binary is started under systemd but has no impact otherwise..." You are no more required to use systemd than you are to run PostgreSQL on Windows but the options are available to you.
Cheers,
Steve
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?"
What exactly does the configure flag to enable systemd support do? It seems to me that building software to the systemd platform is just the same as building it for windows vs unix or any other platform. One can only hope it doesn't cause the others to wither away.
On Wed, Jul 12, 2017 at 3:20 AM, Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk> wrote:
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]
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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