Here’s more info. In the gunicorn stderr, I see:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.7/lib/active_record/connection_adapters/postgresql_adapter.rb:87:in `rescue in new_client': connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory (ActiveRecord::ConnectionNotEstablished)
Is the server running locally and accepting connections on that socket?
In the PG log, I see:
2023-08-21 19:24:00.721 UTC [1681] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-08-21 19:24:00.728 UTC [1681] LOG: could not open configuration file "/etc/postgresql/13/main/pg_hba.conf": Permission denied
2023-08-21 19:24:00.728 UTC [1681] FATAL: could not load pg_hba.conf
2023-08-21 19:24:00.741 UTC [1681] LOG: database system is shut down
further:
# ls -l /etc/postgresql/13/main/pg_hba.conf
-rw-r----- 1 root root 4846 Aug 21 19:05 /etc/postgresql/13/main/pg_hba.conf
What user is postgres running under inside the container? With the above permissions, it has to be root or someone in group root
Ok, so I did chmod o+r /etc/postgresql/13/main/pg_hba.conf and now the container is up again.
This is all a bit concerning - why isn’t the recommended installation method not working out of the box? My plugin status currently includes the ones listed above except data explorer which I disabled since it had caused the failure the last time.
Crosslinking to
which reports similar symptoms.
Update: I changed the git command in the cmd section of the app.yml file to use sudo as described in the linked post.
I am declaring this failure to be intermittent. In 3 tries (between each I completely wiped the shared directory) it succeeded once and failed twice. When it fails, manually fixing the three permissions in question and then restarting the container resulted in what appears to be a working system. Better logging and better self tests would be nice in order to detect failing container bootstraps.