Hi List,

I am trying to understand what After= means in a unit file. Does it mean after the specified target is up and operational or
only that the target has been started?

I have something that needs postgres but postgres needs to be operational not just started. Sometimes it can take a bit
for postgres to become operational.



Re: systemd

By Jonathan Billings at 01/09/2019 - 12:36

On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:
I believe that the postgresql service has Type=notify in it's service
definition, which means that it will notify systemd when it is
operational. This means that if you have a service that has
After=postgresql.service, systemd should wait until after the
postgresql service notifies systemd that it is operational before your
service will be started.

If your service is starting and unable to connect to postgresql, then
I would say that's a bug in postgresql -- it shouldn't be notifying
systemd that it is operational until it actually is.

Re: systemd

By Steve Clark at 01/09/2019 - 13:04

On 01/09/2019 11:36 AM, Jonathan Billings wrote:
from /usr/lib/systemd/system/postgresql.service



Re: systemd

By Jonathan Billings at 01/09/2019 - 14:18

On Wed, Jan 09, 2019 at 12:04:29PM -0500, Steve Clark wrote:
You're right! My mistake.

I was looking at the systemd service for Postgresql 10 (check out the
rh-postgresql10-postgresql-server package in SCL). It seems that
they've managed to get sd_notify notification working in version 10, but
it's still using Type=forking in version 9.

By the way, this isn't really a systemd issue -- even with sysvinit
you'd be stuck trying to figure out when the service was *really* up
in a shell script or something. At least now there's a mechanism to
tell the startup service that the service has actually started, so
proper ordering of services can be automatically performed, rather
than stringing together a collection of shell scripts.

Re: systemd

By Johnny Hughes v... at 01/09/2019 - 13:00

This is, in fact, one of the points why I'm very unhappy with systemd and
the way it is implemented here and most likely in most distributions.

Maybe things _could_ be done the right way with systemd, but it doesn't
happen because it quickly starts to be very complex and it's a lot of work
to do it for a complete distribution. It just doesn't happen - or at least
did not happen in all the years since its introduction.

In this example, PG gets just started with "pg_ctl start" and that's it.


Re: systemd

By Jonathan Billings at 01/09/2019 - 16:50

On Wed, Jan 09, 2019 at 06:00:31PM +0100, Simon Matter via CentOS wrote:
There are a couple ways that systemd can handle service startup in a
way that dependent services can gracefully start up after it. One way
is to have systemd open the socket, then hand it to the service when
it is ready. This requires quite a bit of hacking and I don't think
is as reliable, it's more of the inetd way of doing things.

Another is to have the code send a message when it is ready. This
isn't really that complicated, you can look at the change in
postgresql's git here:

<a href=";a=commitdiff;h=7d17e683fcc28a1b371c7dd02935728cd2cbf9bf" title=";a=commitdiff;h=7d17e683fcc28a1b371c7dd02935728cd2cbf9bf">;a=commitdiff;h=7d17e...</a>

Basically, when the database is ready, it calls the C function:
sd_notify(0, "READY=1");

and when it's shutting down, it runs:
sd_notify(0, "STOPPING=1");

To be honest, that's not too complicated. It does require minor
changes to the code to support systemd, but you can replace idle loops
in shell scripts with a smarter database (which knows when it is
ready) telling PID 1 that it is ready.

Re: systemd

By Gordon Messmer at 01/09/2019 - 16:15

On 1/9/19 9:00 AM, Simon Matter via CentOS wrote:

If you've looked at the sysv init script for postgresql, you know that
that statement describes both init systems.

Systems engineering is hard.  It's fashionable to blame systemd, but
it's not systemd's fault that there's a delay between the point at which
postgresql forks and the point at which it's available for use.  SysV
didn't magically solve that problem. Someone had to specifically write a
delay loop in the init script to make the system work reliably,
beforehand.  PostgreSQL isn't alone in that.  Other services needed
their own hacks.  And collectively, "Maybe things _could_ be done the
right way with SysV, but it doesn't happen because it quickly starts to
be very complex and it's a lot of work to do it for a complete

Re: systemd

By Valeri Galtsev at 01/09/2019 - 14:18

On 1/9/19 11:00 AM, Simon Matter via CentOS wrote:
Yes, introduction of systemd earned Linuxes a lot of refugees. I in my
worst times feel maybe that was the goal of it. But then I think about a
split of refugees from Linux to UNIX descendants (FreeBSD, NettBSD etc.)
vs to MS products, and I am not quite certain if that was a goal (though
I do remember MS alliance with RedHat...), but if it was the goal I
doubt refugee split was in MS favor (though one says something is better
than nothing).

I hope, this didn't come as a rant, I should probably have used rant
tags ;-)