Je rencontre un problème au démarrage de PostgreSQL lorsque j’essaie de reconstruire mon application, et j’espère obtenir de l’aide.
Voici le journal, il est bloqué sur ce statut depuis plus de 30 minutes.
Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1] INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1] INFO -- : File > /etc/service/postgres/run chmod: +x chown:
I, [2024-08-26T17:16:15.362740 #1] INFO -- : File > /etc/service/postgres/log/run chmod: +x chown:
I, [2024-08-26T17:16:15.367767 #1] INFO -- : File > /etc/runit/3.d/99-postgres chmod: +x chown:
I, [2024-08-26T17:16:15.372845 #1] INFO -- : File > /root/install_postgres chmod: +x chown:
I, [2024-08-26T17:16:15.377501 #1] INFO -- : File > /root/upgrade_postgres chmod: +x chown:
I, [2024-08-26T17:16:15.377876 #1] INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1] INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1] INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1] INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1] INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1] INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1] INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1] INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1] INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1] INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1] INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1] INFO -- : Replacing (?-mix:^host.*all.*all.*::1\\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1] INFO -- : > if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1] INFO -- : Generating locales (this might take a while)...
Generation complete.
I, [2024-08-26T17:16:15.453058 #1] INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1] INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG: starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG: listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG: database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG: database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG: redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG: invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG: redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG: database system is ready to accept connections```
Je rencontre le même problème depuis quelques jours en essayant de reconstruire. Je n’arrive pas à faire fonctionner ou reconstruire Discourse sans problème.
J’ai essayé d’utiliser la capacité de démarrage/arrêt et cela n’a pas semblé fonctionner. La VM elle-même a également été redémarrée plusieurs fois. Elle continue de se bloquer à cette ligne concernant la base de données prête à accepter les connexions.
Control-C n’a pas fonctionné et j’ai essayé plusieurs choses, y compris revenir aux anciennes versions, mais dès que j’ai essayé la reconstruction, elle s’est bloquée exactement au même endroit.
J’ai réussi à faire plus de progrès. Dans /var/discourse/ sur mon serveur, j’ai récupéré le commit b1108913820edd27f869634d0fc654639758889a. Ce commit date de quelques jours et n’a pas ces trois commits (1, 2, 3) dans l’historique de discourse_docker. Je soupçonne que l’un de ces changements est la raison du problème de blocage de postgres.
Bref, j’ai enfin réussi à relancer l’application. Ce fut une expérience horrible lol
Même problème ici lors de la mise à niveau de la version 3.3.0 à la version 3.3.1. La mise à niveau reste bloquée à la même ligne de journal (le système de base de données est prêt à accepter les connexions).
Le redémarrage aide ou simplement l’arrêt du processus de mise à niveau et l’exécution de ./launcher start app. La nouvelle version 3.3.1 est affichée. Mais je ne suis pas sûr que ce soit une procédure saine.
Je viens de faire une nouvelle installation sur une nouvelle VM Digital Ocean, puis j’ai exécuté une reconstruction et cela a fonctionné sans problème.
La façon dont j’ai résolu le problème a été de démarrer une nouvelle gouttelette et de faire une nouvelle installation, puis de restaurer la sauvegarde, et la reconstruction fonctionne bien.
J’ai également une sauvegarde d’une version fonctionnelle (qui est sur une version légèrement plus ancienne), mais dès que j’ai mis à niveau vers la dernière version via la reconstruction, j’ai rencontré le même problème, donc je soupçonne qu’il y a quelque chose qui a été introduit avec un commit récent et qui ne casse que la mise à jour de l’ancienne vers la nouvelle version.
Je fais juste remonter ce sujet car j’ai également rencontré ce problème depuis le commit ci-dessus. J’ai essayé tout ce qui précède pour résoudre le problème.
x86. Je suis sur Ubuntu Bionic pour le système d’exploitation hôte… peut-être que cela a une conséquence. Je ne sais pas quel est le système d’exploitation des autres.
Juste quelques informations supplémentaires pour aider à enquêter sur le problème.
Je vois cela sur un hôte exécutant Ubuntu 18.04.6, mais un autre hôte a également été mis à jour aujourd’hui avec la même version d’Ubuntu et la reconstruction de Discourse s’est déroulée normalement.
Je vais mettre à niveau Ubuntu sur l’hôte affecté et voir si cela aide. Je tiendrai tout le monde informé.
Pour ceux qui sont concernés, pouvez-vous exécuter la commande ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" et me dire si la sortie diffère de celle ci-dessous ?
drwxr-xr-x 2 101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19 101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x 3 101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x 2 103 106 4.0K Aug 29 01:38 redis_data
Sortie de la VM rencontrant un problème de reconstruction :
drwxr-xr-x 2 101 104 4.0K Jun 15 2020 postgres_backup
drwx------ 19 101 104 4.0K May 3 2022 postgres_data
drwxrwsr-x 5 101 104 4.0K May 3 2022 postgres_run
drwxr-xr-x 2 103 106 4.0K May 3 2022 redis_data
Juste une note, quelque chose d’un peu différent dans mon cas.
La reconstruction s’est bloquée sur « Le système de base de données est prêt à accepter les connexions » comme d’autres l’ont vu. J’ai dû redémarrer la VM et exécuter ./launcher start app pour démarrer les Forums. Cependant, lorsque Discourse est revenu en ligne, la version de Discourse est restée à la version précédente 3.3.0.beta4-dev.
Je ne suis pas en mesure d’effectuer la mise à niveau d’Ubuntu aujourd’hui, mais je tiendrai tout le monde informé lorsque je le pourrai et si la reconstruction réussit alors.
J’ai mis à niveau notre instance de développement vers Ubuntu 20.6 aujourd’hui et la reconstruction/mise à niveau a réussi vers Discourse 3.4.0.beta2-dev. Cependant, c’était l’hôte qui a également été reconstruit sans problème sur Ubuntu 18.4 hier.