C’est la première fois que je vois l’erreur suivante en essayant de reconstruire.
2022-10-04 14:39:49.780 UTC [1700] FATAL: lock file "postmaster.pid" is empty
2022-10-04 14:39:49.780 UTC [1700] HINT: Either another server is starting, or the lock file is the remnant of a previous server startup crash.
Je peux évidemment lire l’indice, mais je ne sais pas comment procéder. Quelqu’un peut-il m’éclairer ?
Quand cela se produit-il ? S’agit-il d’une installation standard ?
Installation standard et après exécution de ./launcher rebuild app
Essayez peut-être un
./launcher start app
Est-ce que cela a fonctionné auparavant ?
S’agit-il d’une erreur ou d’un avertissement. Avez-vous essayé d’ouvrir dans votre navigateur ?
Que dit
docker ps
Réponse à ./launcher start app :
57c2a0746e93
Rien à faire, votre conteneur a déjà démarré !
Et ensuite, dans le navigateur, j’obtiens 502 Bad Gateway.
sortie de docker ps
ID DU CONTENEUR IMAGE COMMANDE CRÉÉ STATUT PORTS NOMS
57c2a0746e93 local_discourse/app « /sbin/boot » Il y a 6 mois En cours d'exécution depuis 16 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp app
C’est étrange. Je pense que je vais redémarrer et reconstruire à nouveau.
Ou peut-être
./launcher stop app; ./launcher rebuild app
Vous exécutez un conteneur ancien, pas celui que vous venez de construire (créé il y a 6 mois).
Et peut-être y a-t-il eu d’autres erreurs dans la reconstruction que vous n’avez pas remarquées.
Même résultat
2022-10-04 15:26:43.452 UTC [1699] FATAL: le fichier de verrouillage « postmaster.pid » est vide
2022-10-04 15:26:43.452 UTC [1699] HINT: Soit un autre serveur est en cours de démarrage, soit le fichier de verrouillage est le vestige d'un crash de démarrage précédent du serveur.
Il n’y a pas assez de données ici pour déboguer.
Cela se produit car le processus de build pense que PG est déjà en cours d’exécution, donc peut-être que quelque chose concernant le processus de mise à niveau de PG est erroné. Pouvez-vous inclure les journaux complets du lanceur (en supprimant les mots de passe) afin que nous puissions voir ce qui se passe.
Peut-être qu’il serait utile de regarder un système qui fonctionne correctement. Je vois mon fichier de verrouillage ici :
# ls -l /var/discourse/shared/standalone/postgres_data/postmaster.pid
-rw------- 1 systemd-resolve input 92 Nov 15 16:20 /var/discourse/shared/standalone/postgres_data/postmaster.pid
et le 15 novembre est la date à laquelle j’ai démarré l’application pour la dernière fois. Si j’entre dans l’application, je peux voir les processus postgres :
# cd /var/discourse/
# ./launcher enter app
x86_64 arch detected.
# ps auxfc|egrep -1 postm
root 45 0.0 0.0 2332 0 ? S Nov15 0:00 \_ svlogd
postgres 48 0.0 0.1 213160 1784 ? S Nov15 0:27 \_ postmaster
postgres 67 0.0 2.6 213380 26924 ? Ss Nov15 0:34 \_ postmaster
postgres 68 0.0 0.4 213292 4236 ? Ss Nov15 0:15 \_ postmaster
postgres 69 0.0 0.1 213160 1068 ? Ss Nov15 3:44 \_ postmaster
postgres 70 0.0 0.1 213840 1520 ? Ss Nov15 0:16 \_ postmaster
postgres 71 0.0 0.0 68184 380 ? Ss Nov15 0:56 \_ postmaster
postgres 72 0.0 0.0 213716 468 ? Ss Nov15 0:00 \_ postmaster
postgres 92 0.0 0.0 225364 324 ? Ss Nov15 0:01 \_ postmaster
postgres 176 0.0 0.1 217944 1484 ? Ss Nov15 0:01 \_ postmaster
postgres 9126 0.0 0.7 215052 7336 ? Ss Nov16 0:19 \_ postmaster
postgres 1574 0.0 5.7 223540 58300 ? Ss 17:28 0:00 \_ postmaster
postgres 1973 0.0 3.3 221032 33960 ? Ss 17:34 0:00 \_ postmaster
postgres 2320 0.1 3.5 218080 36120 ? Ss 17:39 0:00 \_ postmaster
postgres 2321 0.1 2.9 218068 29928 ? Ss 17:39 0:00 \_ postmaster
postgres 2336 0.0 1.4 215052 14340 ? Ss 17:40 0:00 \_ postmaster
# exit
Si j’arrêtais l’application, je m’attendrais à ne pas voir de fichier de verrouillage à cet emplacement, et aucun processus postgres en cours d’exécution. (Je devrais, bien sûr, exécuter la commande ps directement sur l’hôte, car le conteneur ne serait plus en cours d’exécution.)
Dans votre situation, je pense que c’est ce que je ferais en premier : arrêter l’application et vérifier qu’aucun processus postgres n’est en cours d’exécution. Il semble possible que vous ayez deux instances en cours d’exécution qui entrent en collision.
C’est peu probable, mais il est aussi possible que le disque soit plein et que ce soit la raison pour laquelle le fichier de verrouillage est vide. Ou peut-être y a-t-il un problème de permissions d’une manière ou d’une autre.
Modifier : à l’intérieur du conteneur, le fichier de verrouillage a un emplacement et une propriété différents :
# ./launcher enter app
x86_64 arch detected.
# ls -l /shared/postgres_data/postmaster.pid
-rw------- 1 postgres postgres 92 Nov 15 16:20 /shared/postgres_data/postmaster.pid
# exit
logout
#
Comme le note Sam, nous aurions besoin de voir plus d’informations.