View previous topic :: View next topic |
Author |
Message |
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Tue Jun 04, 2024 8:05 am Post subject: [SOLVED] Systemd unit dependency on slotted service |
|
|
Hello everybody,
I would like to load a systemd service after a slotted/versioned service, but being version-agnostic.
Specifically:
My application can use a PostgreSQL database: its service should start at boot time after the PostgreSQL service (think `After=` in systemd). In Gentoo, PostgreSQL is shipped with a systemd `postgresql-<version>.service`.
I want to make my service resistant to PostgreSQL updates, i.e. avoiding `After=postgresql-16.service`
For instance, the following thread creates a dependency over `postgresql-12.service` which is to avoid:
Requires=postgresql-12.service
Is there an elegant way of having a generic `postgresql.service` active whatever the underlying `postgresql-<version>.service`?
Do any of Gentoo virtual packages or `PartOf=` systemd [Unit] parameter be possible solutions?
Here is the systemd service I'm working on:
Code: |
[Unit]
Description=Tryton business software server
# TODO
After=postgresql-16.service
[Service]
Type=simple
User=trytond
EnvironmentFile=/etc/conf.d/trytond
ExecStart=/usr/bin/trytond --config ${CONFIG} --logconf ${LOGCONF} --database ${DATABASES}
Restart=on-failure
[Install]
WantedBy=multi-user.target
|
Thanks!
Last edited by fabalthazar on Fri Jun 07, 2024 12:27 pm; edited 1 time in total |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2422
|
Posted: Tue Jun 04, 2024 8:16 am Post subject: |
|
|
I'm a programmer, so first thing that comes to mind is abstraction. Unfortunately I'm not a systemd expert and what I suggest might not be possible or a good idea:
Create a target for your application and make it depend on the target in which postgresql is started.
Best Regards,
Georgi |
|
Back to top |
|
|
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Wed Jun 05, 2024 2:03 pm Post subject: |
|
|
Abstraction looks interesting.
I imagine this abstracted Unit delivered by the postgresql implementation, or by some kind of virtual package https://wiki.gentoo.org/wiki/Virtual_packages
Not sure if virtual packages are designed for it and if they can ship files and not only dependency relations. |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2422
|
Posted: Wed Jun 05, 2024 2:14 pm Post subject: |
|
|
fabalthazar wrote: | Abstraction looks interesting.
I imagine this abstracted Unit delivered by the postgresql implementation, or by some kind of virtual package https://wiki.gentoo.org/wiki/Virtual_packages
Not sure if virtual packages are designed for it and if they can ship files and not only dependency relations. |
Now that's going too far. This is configuration, deliver it yourself. Or with your application. An ebuild is not the place for standalone configuration. Postgresql implementation (maybe you meant the ebuild/package?) has nothing to do with your application either.
Best Regards,
Georgi |
|
Back to top |
|
|
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Thu Jun 06, 2024 9:49 am Post subject: |
|
|
Let's sum up my initial need:
What is expected by the end user is :
- emerge postgresql
- emerge trytond (via an overlay)
- systemctl enable trytond.service
And that's all.
- The application (Tryton server here), delivered through an existing overlay (https://foss.heptapod.net/tryton/gentoo-overlay), provides a system service. Actually on OpenRC service only but I'm working on a systemd one.
- This app makes use of a postgresql database.
- PostgreSQL only provides versioned services (e.g. postgresql-16.service).
The problematic is:
How to provide these two system services, automatically via Portage without configuration, in order to make the app (Tryton here) system service start after the postgresql service whichever its version.
Then no problem with PostgreSQL updates.
Hence my trytond.service systemd unit draft:
Code: | [Unit]
# The version is not expected here!
After=postgresql-16.service |
Possible? |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2422
|
Posted: Thu Jun 06, 2024 11:00 am Post subject: |
|
|
Add a warning in the ebuild that postgresql service needs to be enabled and let the administrator deal with it. What the ebuild of your application delivers should be only related to your application. No other ebuild should be in any way engaged into delivering something your application needs, neither should your ebuild deliver something pertaining to other applications.
Best Regards,
Georgi |
|
Back to top |
|
|
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Thu Jun 06, 2024 12:51 pm Post subject: |
|
|
logrusx wrote: | Add a warning in the ebuild that postgresql service needs to be enabled and let the administrator deal with it. |
Completely agree with this. I would add that this warning could inform to enable the app service as well (trytond.service).
logrusx wrote: | No other ebuild should be in any way engaged into delivering something your application needs, neither should your ebuild deliver something pertaining to other applications. |
I am aware of atomicity and loose coupling architecture principles but I'm not sure if this is correct. Let's take an example:
systemd-ask-password-console.service has an "After=" runtime ordering dependency on plymouth-start.service whereas the plymouth package is optional and is not even installed on my system.
It simply adds a runtime ordering dependency in case the package is present and that's exactly what I'm looking for. Of course this should be as generic as possible.
Then reading further what systemd targets are (man systemd.target), that seems exactly what I expect postgresql to deliver: a postgresql.target saying no more than "Hey one of PostgreSQL services exists and you can rely on it through the postgresql.target unit", however one or more PostgreSQL slots are installed. |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2422
|
Posted: Thu Jun 06, 2024 2:03 pm Post subject: |
|
|
fabalthazar wrote: |
systemd-ask-password-console.service has an "After=" runtime ordering dependency on plymouth-start.service whereas the plymouth package is optional and is not even installed on my system.
|
It's that simple if you only needed to add a dependency on a service. You want to add something more than that which involves more than one package. You expressed an opinion it can be added by postgresql implementation, whatever you might mean by postgresql implementation, you should not do that. And since I don't see a way you could add it through the ebuild of your application, the only option left is to warn the admin and include it in the documentation.
And after all my idea with the new target does not solve anything because somebody should still add the postgresql service to the target to which your unit should depend on. Even if you add some code to the ebuild to retrieve what the current name of postgresql service is, it might get updated and boom.
So wanr the user and let them deal with their system.
Best Regards,
Georgi |
|
Back to top |
|
|
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Thu Jun 06, 2024 8:59 pm Post subject: |
|
|
I see. As is, PostgreSQL is slotted certainly because apps should stick to specific compatible versions/slots.
In effect, the admins already have to manually enable specific versions. Currently: postgresql-16.service for the last stable version. Furthermore, one has to manually migrate databases from one major version to another.
So I abandon the idea of PostgreSQL providing a unique way or declaring its availability. It is against its design.
If I focus on the idea of making the app depend on PostgreSQL, then it could simply specify in its ebuild the exact PostgreSQL version it depends on (and is compatible with). My example of Tryton app already has a "postgres" USE flag.
Let add one line to the ebuild:
Code: | RDEPEND="postgres? (
>=dev-python/psycopg-2.7.0:2[$PYTHON_USEDEP]
dev-db/postgresql:16[$PYTHON_USEDEP]
)" |
Then my initial suggestion of systemd runtime ordering dependency makes sense (trytond.service):
Code: | [Unit]
After=postgresql-16.service |
And all the requirements are satisfied:
- Guarantee PostgreSQL compatibility. Up to the app ebuild maintainer to follow PostgreSQL updates.
- Guarantee the compatible PostgreSQL server is started before the app attempts to send requests to it.
Does it fit more to the Gentoo slotting philosophy? |
|
Back to top |
|
|
logrusx Advocate
Joined: 22 Feb 2018 Posts: 2422
|
Posted: Fri Jun 07, 2024 7:35 am Post subject: |
|
|
fabalthazar wrote: | I see. As is, PostgreSQL is slotted certainly because apps should stick to specific compatible versions/slots.
In effect, the admins already have to manually enable specific versions. Currently: postgresql-16.service for the last stable version. Furthermore, one has to manually migrate databases from one major version to another.
So I abandon the idea of PostgreSQL providing a unique way or declaring its availability. It is against its design.
If I focus on the idea of making the app depend on PostgreSQL, then it could simply specify in its ebuild the exact PostgreSQL version it depends on (and is compatible with). My example of Tryton app already has a "postgres" USE flag.
Let add one line to the ebuild:
Code: | RDEPEND="postgres? (
>=dev-python/psycopg-2.7.0:2[$PYTHON_USEDEP]
dev-db/postgresql:16[$PYTHON_USEDEP]
)" |
Then my initial suggestion of systemd runtime ordering dependency makes sense (trytond.service):
Code: | [Unit]
After=postgresql-16.service |
And all the requirements are satisfied:
- Guarantee PostgreSQL compatibility. Up to the app ebuild maintainer to follow PostgreSQL updates.
- Guarantee the compatible PostgreSQL server is started before the app attempts to send requests to it.
Does it fit more to the Gentoo slotting philosophy? |
Well, I'm not sure it's philosophy, more like a solution to a technical problem. Yes, that looks reasonable, but more importantly - pragmatic. You don't need to go to make decisions for the user, so keep it that way and let the administrator make the decisions however they best see fit. Sometimes keeping things simple is better. Also you don't need to great lengths to make it look like what you think is the Gentoo philosophy.
Best Regards,
Georgi |
|
Back to top |
|
|
fabalthazar n00b
Joined: 26 May 2015 Posts: 27 Location: France
|
Posted: Fri Jun 07, 2024 12:26 pm Post subject: [SOLVED] Systemd unit dependency on slotted service |
|
|
Thanks. Let's mark it as solved. |
|
Back to top |
|
|
|