ArgumentError: directory per pid=/.../unicorn.pid non scrivibile

Ecco altre informazioni. Nello stderr di gunicorn, vedo:

/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?

Nel log di PG, vedo:

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

inoltre:

# 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

Sotto quale utente viene eseguito postgres all’interno del container? Con i permessi sopra indicati, deve essere root o qualcuno nel gruppo root.

Ok, ho eseguito chmod o+r /etc/postgresql/13/main/pg_hba.conf e ora il container è di nuovo attivo.

Tutto questo è un po’ preoccupante: perché il metodo di installazione consigliato non funziona subito? Lo stato dei miei plugin include attualmente quelli elencati sopra, ad eccezione di data explorer che ho disabilitato poiché aveva causato il fallimento l’ultima volta.

Cross-linking a

che riporta sintomi simili.

Aggiornamento: ho modificato il comando git nella sezione cmd del file app.yml per utilizzare sudo come descritto nel post collegato.

Dichiaro che questo fallimento è intermittente. In 3 tentativi (tra ogni tentativo ho completamente cancellato la directory shared) è riuscito una volta e fallito due volte. Quando fallisce, la correzione manuale dei tre permessi in questione e il successivo riavvio del container hanno portato a quello che sembra essere un sistema funzionante. Sarebbero utili un logging migliore e test automatici più efficaci per rilevare i fallimenti nell’avvio dei container.