Soudainement, Discourse ne veut plus démarrer et ne se reconstruit même pas avec ./launcher rebuild app. J’ai aussi commenté tous les plugins.
Voici les logs lorsque j’essaie de le démarrer : https://codefile.io/f/8XUuOqyEDd
Voici les logs lorsque j’utilise ./launcher rebuild app. Je vois quelque chose à propos de « failed listening on port 6379 (TCP) aborting » mais rien ne tourne sur ce port !
Je ne pense pas que ce soit lié à votre problème. Cet avertissement apparaît souvent (toujours ?) lors d’une reconstruction.
error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: Connection refused
Je pense que votre problème vient plutôt de là.
Cela pourrait donner des indices :
Est-ce que ce serait ce qui empêche son fonctionnement lorsque je l’exécute (sans faire un ./launcher rebuild app) ?
J’ai arrêté tous les autres services sur mon serveur et mis à jour vers la dernière version LTS d’Ubuntu et il affiche toujours ceci :
PG::ConnectionBad: échec de la connexion au serveur sur la socket "/var/run/postgresql/.s.PGSQL.5432" : Connexion refusée (PG::ConnectionBad)
Le serveur fonctionne-t-il localement et accepte-t-il les connexions sur cette socket ?
Ce que je penserais être l’erreur.
L’échange des modèles avec 13 et même 15 n’a pas résolu le problème, ce qui est ce qui a été montré dans le post référencé.
Causé par :
PG::ConnectionBad : la connexion au serveur sur le socket « /var/run/postgresql/.s.PGSQL.5432 » a échoué : Aucun fichier ou répertoire de ce type (PG::ConnectionBad)
Le serveur fonctionne-t-il localement et accepte-t-il les connexions sur ce socket ?
timeout: down: postgres: 1s, normally up, want up
Il semble que la base de données ne démarre pas correctement. Les journaux montrent qu’elle démarre occasionnellement correctement, mais seulement pour une courte période, ce qui pourrait donc être une fausse piste.
ok: run: postgres: (pid 315501) 0s
Les journaux de postgres pourraient donner un indice sur le problème, en particulier lors de la tentative de démarrage du conteneur de l’application.
tail -f shared/standalone/log/var-log/postgres/current
Avez-vous effectué la mise à jour PostgreSQL 15 ?
Je pense aussi que cela est dû à un arrêt non propre. Si vous avez une sauvegarde, ce que je ferais, c’est de lancer une nouvelle VM et de la restaurer. Vous pouvez suivre Déplacer un site Discourse vers un autre VPS avec rsync et exclure postgres_*.
L’alternative, qui est votre seule option si vous n’avez pas de sauvegarde, sera de comprendre un tas de choses sur PostgreSQL que vous ne voudrez pas apprendre.
Comment puis-je accéder à mes sauvegardes si mon forum est en panne (c’est-à-dire que je ne peux pas aller dans les paramètres d’administration et télécharger une sauvegarde) ?
Je n’ai également pas essayé de migrer quoi que ce soit, je l’ai utilisé normalement et mis à jour via l’interface Web. Pourquoi la base de données aurait-elle subi une fermeture non propre ?
Je vais fournir les journaux Postgres, une seconde
2025-03-22 00:30:44.110 UTC [4922] FATAL : le fichier de verrouillage « postmaster.pid » est vide
2025-03-22 00:30:44.110 UTC [4922] HINT : soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d’un précédent crash de démarrage de serveur.
2025-03-22 00:30:45.127 UTC [4964] FATAL : le fichier de verrouillage « postmaster.pid » est vide
2025-03-22 00:30:45.127 UTC [4964] HINT : soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d’un précédent crash de démarrage de serveur.
2025-03-22 00:30:46.151 UTC [4966] FATAL : le fichier de verrouillage « postmaster.pid » est vide
2025-03-22 00:30:46.151 UTC [4966] HINT : soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d’un précédent crash de démarrage de serveur.
2025-03-22 00:30:47.168 UTC [4970] FATAL : le fichier de verrouillage « postmaster.pid » est vide
2025-03-22 00:30:47.168 UTC [4970] HINT : soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d’un précédent crash de démarrage de serveur.
2025-03-22 00:30:48.192 UTC [4977] FATAL : le fichier de verrouillage « postmaster.pid » est vide
2025-03-22 00:30:48.192 UTC [4977] HINT : soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d’un précédent crash de démarrage de serveur.
-rw------- 1 syslog kvm 0 18 mars 19:48 /var/discourse/shared/standalone/postgres_data/postmaster.pid
C’est là que se trouve mon fichier de verrouillage
Ils se trouvent dans /var/discourse/shared/standalone/backups/default
Si vous suivez les instructions rsync que j’ai liées précédemment, vous les obtiendrez.
Elle a planté ou le serveur a redémarré ou quelque chose s’est passé.
La base de données est « migrée » d’un ensemble de tables (les tables sont ajoutées et modifiées) à un autre lors de la plupart des mises à niveau.
Vous pourriez essayer d’arrêter le conteneur et de supprimer ce fichier de verrouillage
Et regardez dans PG_VERSION pour voir quelle version vous avez, car je pense que vous avez essayé de changer le modèle.
Oui, j’ai essayé de changer après avoir vu l’erreur.
Alors, est-ce que je devrais faire rm /var/discourse/shared/standalone/postgres_data/postmaster.pid ? pour supprimer le fichier de verrouillage puis essayer de reconstruire
Merci aussi de m’avoir aidé avec ça.
Je ferais cette commande pour supprimer le fichier de verrouillage ?
rm /var/discourse/shared/standalone/postgres_data/postmaster.pid était la solution, merci !
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.