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

...

On Wed, Jan 09, 2019 at 10:43:38AM -0500, Steve Clark wrote:

...

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.

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.

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.

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 ;-)

Valeri

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

Regards, Simon

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Wed, Jan 09, 2019 at 06:00:31PM +0100, Simon Matter via CentOS wrote:

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.

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:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7d17e683f...

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.

On Wed, Jan 09, 2019 at 12:04:29PM -0500, Steve Clark wrote:

Hmm... I don't see that in the postgresql.service file - this is CentOS Linux release 7.5.1804 (Core) postgresql-server-9.2.24-1.el7_5.x86_64

from /usr/lib/systemd/system/postgresql.service ... [Service] Type=forking

User=postgres Group=postgres

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.