Bonjour, je rencontre deux gros problèmes lors de l’arrêt et du redémarrage de Discourse.
Premièrement
Après 2 ou 3 tentatives (peu importe que ce soit via ./launcher stop ou via Portainer), le conteneur refuse de redémarrer et reste bloqué en boucle sur le message : “rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory”. (Je viens de remarquer que le socket ne se trouve pas dans le répertoire “shared”, mais dans “shared/standalone”. S’agit-il d’une erreur dans le message ?)
Pour une raison qui m’échappe encore, ce socket devient peut-être un répertoire après l’arrêt, et le modèle ne parvient pas à le supprimer car il tente de supprimer un répertoire alors qu’il s’agit d’un socket. Le supprimer manuellement ne change rien ; il réapparaît à chaque fois.
Deuxièmement
La commande ./launcher rebuild app se bloque sur “FATAL: the database system is starting up”, après le premier message “PANIC could not locate a valid checkpoint record”. J’ai lu et essayé tout ce que j’ai trouvé concernant ce problème, et la seule “solution” qui fonctionne est de supprimer le répertoire discourse avec tout son contenu et de tout reconfigurer… ce qui n’est évidemment pas une vraie solution !
Il semble que l’arrêt du conteneur Discourse laisse parfois la base de données dans un état corrompu, et elle ne peut pas continuer car elle indique “is starting up”, peut-être en essayant de réparer quelque chose. Mais je n’ai toujours pas trouvé comment résoudre ce problème, qui semble survenir après plusieurs arrêts et redémarrages.
Une idée ? Un moyen de laisser Postgres corriger ses propres problèmes ?
Non, ce n’est pas une erreur. Ce fichier se trouve dans le volume monté dans le conteneur, il a donc des chemins différents selon le point de vue, c’est-à-dire à l’intérieur du conteneur par rapport à l’extérieur du conteneur.
Cela se produit lorsque le conteneur n’est pas arrêté correctement. PostgreSQL a besoin de temps pour s’arrêter proprement, et nous le faisons lorsque vous utilisez notre commande de lancement pour arrêter. Cependant, si votre instance est assez grande ou s’il y a trop de transactions en cours d’exécution, la base de données peut avoir du mal à s’arrêter correctement dans le délai imparti.
Cependant, je trouve que ce fichier “nginx.http.sock” est également créé dans “shared/standalone” sur le système de fichiers de l’hôte. Initialement rose, en tant que socket, mais après un certain temps, peut-être un arrêt, il devient bleu, comme un répertoire, et le conteneur refuse de démarrer, bloqué en train de tenter de supprimer un socket… qui est devenu un répertoire.
Alors, que pouvons-nous faire pour régler ce problème ? Jusqu’à présent, je fais juste des essais, mais si je passe en ligne avec quelques centaines de personnes connectées et des centaines de milliers de publications, risque-je de tout perdre simplement parce que PostgreSQL ne gère pas bien les interruptions brutales ? Il y aura quelque chose à faire pour réparer une base de données endommagée. Discourse peut-il fonctionner avec une base de données PostgreSQL externe, quelque chose que nous pourrions gérer si le conteneur Discourse ne démarre pas ? En bref, en cas de “PANIC” ou “FATAL”, il devrait y avoir une solution…
En fait, j’essaie de résoudre le problème (pour le futur) en configurant une instance Postgres « conteneurisée » et en la reliant à Discourse, dans l’espoir de ne pas endommager la base de données (ou du moins de pouvoir effectuer une maintenance même lorsque Discourse est hors ligne) lors de l’arrêt de Discourse.