Voici plus d’informations. Dans le stderr de gunicorn, je vois :
/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?
Dans le log de PG, je vois :
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
ensuite :
# 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
Sous quel utilisateur postgres s’exécute-t-il dans le conteneur ? Avec les permissions ci-dessus, ce doit être root ou quelqu’un du groupe root.
Ok, j’ai donc fait chmod o+r /etc/postgresql/13/main/pg_hba.conf et le conteneur est maintenant de nouveau opérationnel.
Tout cela est un peu préoccupant - pourquoi la méthode d’installation recommandée ne fonctionne-t-elle pas immédiatement ? Mon statut de plugin inclut actuellement ceux mentionnés ci-dessus, à l’exception de data explorer que j’ai désactivé car il avait causé l’échec la dernière fois.
Lien croisé vers
qui rapporte des symptômes similaires.
Mise à jour : J’ai modifié la commande git dans la section cmd du fichier app.yml pour utiliser sudo comme décrit dans le post lié.
Je déclare que cet échec est intermittent. En 3 tentatives (entre chaque, j’ai complètement effacé le répertoire shared), cela a réussi une fois et échoué deux fois. Lorsque cela échoue, la correction manuelle des trois permissions en question, puis le redémarrage du conteneur ont abouti à ce qui semble être un système fonctionnel. Une meilleure journalisation et de meilleurs auto-tests seraient utiles pour détecter les échecs de démarrage de conteneur.