Closed chrisjsewell closed 3 years ago
It appears that on redhat the database cluster always needs to be created. On CentOS8:
[root@instance /]# systemctl status postgresql.service
● postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2020-12-05 02:54:43 UTC; 48s ago
Process: 1291 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=1/FAILURE)
Dec 05 02:54:43 instance systemd[1]: Starting PostgreSQL database server...
Dec 05 02:54:43 instance systemd[1]: postgresql.service: Control process exited, code=exited status=1
Dec 05 02:54:43 instance systemd[1]: postgresql.service: Failed with result 'exit-code'.
Dec 05 02:54:43 instance systemd[1]: Failed to start PostgreSQL database server.
[root@instance /]# journalctl -xe
-- Unit session-c14.scope has finished starting up.
--
-- The start-up result is RESULT.
Dec 05 02:54:42 instance sudo[1269]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 05 02:54:42 instance ansible-ansible.legacy.systemd[1271]: Invoked with name=postgresql state=started enabled=True daem>
Dec 05 02:54:42 instance systemd[1]: Reloading.
Dec 05 02:54:43 instance systemd[1]: Starting PostgreSQL database server...
-- Subject: Unit postgresql.service has begun start-up
-- Defined-By: systemd
-- Support: https://access.redhat.com/support
--
-- Unit postgresql.service has begun starting up.
Dec 05 02:54:43 instance postgresql-check-db-dir[1291]: Directory "/var/lib/pgsql/data" is missing or empty.
Dec 05 02:54:43 instance postgresql-check-db-dir[1291]: Use "/usr/bin/postgresql-setup --initdb"
Dec 05 02:54:43 instance postgresql-check-db-dir[1291]: to initialize the database cluster.
Dec 05 02:54:43 instance postgresql-check-db-dir[1291]: See /usr/share/doc/postgresql/README.rpm-dist for more information.
Dec 05 02:54:43 instance systemd[1]: postgresql.service: Control process exited, code=exited status=1
Dec 05 02:54:43 instance systemd[1]: postgresql.service: Failed with result 'exit-code'.
Dec 05 02:54:43 instance systemd[1]: Failed to start PostgreSQL database server.
-- Subject: Unit postgresql.service has failed
-- Defined-By: systemd
-- Support: https://access.redhat.com/support
--
-- Unit postgresql.service has failed.
--
-- The result is RESULT.
Dec 05 02:54:43 instance sudo[1269]: pam_unix(sudo:session): session closed for user root
Dec 05 02:55:10 instance systemd[1]: systemd-logind.service: Got notification message from PID 59, but reception is disable>
I didn't realise before, but the geerlinguy docker images are set up to start by default with systemd. This allows for the tests to run in an environment more closely representing that of the Quantum Mobile VM, and won't skip all the systemd tasks.
Yes. This is a bit outside the PR, but I will ask anyway. Do we have an official AiIDA stance on systemd
or not? I am working on the scheduler containers and made an effort to stay away from systemd
in the AiiDA context. Obviously that is not always straightforward, but keeps it completely isolated.
Do we have an official AiIDA stance on systemd or not?
Well, in terms of Quantum Mobile, my stance is that, if its good enough for geerlingguy (the godfather of ansible lol) then its good enough for me lol. Plus, to my knowledge, it's the mostly widely used service manager on Linux. Are there any drawbacks of systemd that you know of?
I would tangentially note though that, in the context of (Docker) containers, really the idea is to only have one service per container, so then you should not need a service manager because essentially the docker daemon itself is the service manager, i.e. managing the container lifespan. (In this PR the containers are principally being used as a representation of a VM for testing, rather than for actual production use.)
On a semi-related note Podman is actually a lot better at integrating with systemd; both inside the container (https://developers.redhat.com/blog/2019/04/24/how-to-run-systemd-in-a-container/) and for systemd managing the actual containers as services (https://www.redhat.com/sysadmin/podman-shareable-systemd-services)
I am working on the scheduler containers
I'm not sure that I've heard of this work. Out of interest, what are the goal of these, and are they located in a repository somewhere?
Well, in terms of Quantum Mobile, my stance is that, if its good enough for geerlingguy (the godfather of ansible lol) then its good enough for me lol. Plus, to my knowledge, it's the mostly widely used service manager on Linux. Are there any drawbacks of systemd that you know of?
Pros and cons with everything, but I was referring mainly to the idea behind containers and the way they are done in Docker. What you also refer to. One can discuss forever if this is a good principle to pin, but I think we should be pragmatic about it and hence my question I thus understand from you that we do not have a particular opinion on systemd
or not in our service containers and that we indeed want to follow a pragmatic approach. For most service containers allowing systemd
surely simplifies implementation.
Let us take the scheduler discussions on Slack.
I didn't realise before, but the geerlinguy docker images are set up to start by default with systemd. This allows for the tests to run in an environment more closely representing that of the Quantum Mobile VM, and won't skip all the systemd tasks.