PostgreSQL bleibt beim Neuaufbau hängen

Installation
1

Hallo zusammen,

Ich habe ein Problem mit dem Start von PostgreSQL, als ich versucht habe, meine App neu zu erstellen, und hoffe, Hilfe zu bekommen.

Hier ist das Protokoll, es hängt seit über 30 Minuten in diesem Status fest.

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```
2

Es wurde nicht sauber heruntergefahren und hat versucht, Dinge zu reparieren, und es glaubt, dass es das getan hat.

Versuchen Sie vielleicht, es mit Strg+C zu beenden und zu sehen, ob Sie ./launcher start app ausführen können, um den alten Container wieder zum Laufen zu bringen.

Wenn es funktioniert, können Sie versuchen, ./launcher stop app erneut auszuführen und dann neu zu erstellen.

3 „Gefällt mir“
3

Ich stoße in den letzten Tagen beim Versuch, neu zu erstellen, auf dasselbe Problem. Ich kann Discourse nicht ohne Probleme ausführen oder neu erstellen.

Ich habe versucht, die Start-/Stoppfunktion zu verwenden, und es schien nicht zu funktionieren. Die VM selbst wurde ebenfalls ein paar Mal neu gestartet. Sie bleibt immer an dieser Zeile hängen, in der es darum geht, dass die Datenbank bereit ist, Verbindungen zu akzeptieren.

4

Strg-C funktionierte nicht und ich habe viele verschiedene Dinge versucht, einschließlich des Zurücksetzens auf alte Versionen, aber sobald ich den Wiederaufbau versuchte, blieb er an derselben Stelle stecken.

5

Wie viel RAM hast du? Ist deine Netzwerkverbindung langsam?

6

Was mein Problem betrifft… reichlich RAM… 8 GB. Netzwerk ist in Ordnung

7

4 GB RAM, ich habe Netzwerk, Festplattenauslastung, CPU-Auslastung, RAM-Auslastung überprüft, alles sieht in Ordnung aus.

8

Ich konnte weitere Fortschritte erzielen. In /var/discourse/ auf meinem Server habe ich den Commit b1108913820edd27f869634d0fc654639758889a ausgecheckt. Dieser Commit ist ein paar Tage alt und enthält nicht diese drei Commits (1, 2, 3) in der discourse_docker-Historie. Ich vermute, dass eine dieser Änderungen der Grund für das hängende Postgres-Problem ist.

Auf jeden Fall ist die App jetzt wieder hochgefahren. Das war eine schreckliche Erfahrung, lol.

3 „Gefällt mir“
11

Gleiches Problem hier beim Upgrade von 3.3.0 auf 3.3.1. Das Upgrade bleibt bei derselben Log-Zeile hängen (database system is ready to accept connections).

Ein Neustart hilft oder das Beenden des Upgrade-Prozesses und ./launcher start app. Die neue Version 3.3.1. wird angezeigt. Aber ich bin mir nicht sicher, ob dies ein sinnvolles Vorgehen ist.

13

Das sind also vier Leute mit einem Problem, glaube ich.

Hattet ihr, die Probleme hatten, Probleme mit ARM oder mit Intel?

1 „Gefällt mir“
14

Das ist eine gute Frage.

Ich habe gerade eine Neuinstallation auf einer neuen Digital Ocean VM durchgeführt und dann einen Rebuild ausgeführt, und es hat einwandfrei funktioniert.

15

Ich verwende Intel.

Die Art und Weise, wie ich das Problem gelöst habe, war, dass ich einen neuen Droplet starten, eine Neuinstallation durchführen und das Backup wiederherstellen musste, dann funktionierte der Rebuild einwandfrei.

Ich habe auch ein Backup einer funktionierenden Version (die eine etwas ältere Version ist), aber sobald ich über den Rebuild auf die neueste Version aktualisiert habe, trat dasselbe Problem auf, daher vermute ich, dass etwas mit dem letzten Commit eingeführt wurde und nur alte → neue Version-Updates unterbricht.

1 „Gefällt mir“
16

Verdammt.

Hmm. Ich werde sehen, ob ich eine Seite habe, bei der es mir egal ist, ob sie abstürzt.

Ich schätze, Sie haben eine Standard-1-Container-Standardinstallation. Ich werde sehen, ob ich eine davon finden kann.

17

Dies wird hochgeschoben, da ich dieses Problem seit dem obigen Commit ebenfalls sehe. Habe auch alles oben versucht, um das Problem zu lösen.

2 „Gefällt mir“
18

x86. Ich bin auf Ubuntu Bionic für das Host-Betriebssystem… vielleicht ist das von Bedeutung. Ich weiß nicht, welches Betriebssystem andere haben.

19

Es ist über ein Jahr nach dem Ende des Lebenszyklus (EOL). https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices.

Es ist nicht zu früh, eine neue VM zu starten und dorthin zu wechseln.

4 „Gefällt mir“
20

Nur einige weitere Informationen zur Untersuchung des Problems.

Dies wird auf einem Host mit Ubuntu 18.04.6 angezeigt, aber ein anderer Host wurde heute ebenfalls mit derselben Ubuntu-Version aktualisiert und der Discourse-Neustart verlief normal.

Ich werde Ubuntu auf dem betroffenen Host aktualisieren und sehen, ob dies hilft. Ich werde alle auf dem Laufenden halten.

2 „Gefällt mir“
21

Können Sie für die Betroffenen den Befehl ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" ausführen und mir mitteilen, ob die Ausgabe von der unten stehenden abweicht?

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
1 „Gefällt mir“
22 
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dez 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data
2 „Gefällt mir“
23

Ausgabe von VM mit Wiederaufbauproblem:

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

Nur eine Anmerkung, in meinem Fall etwas anders.
Der Wiederaufbau blieb bei The database system is ready to accept connections hängen, wie andere auch gesehen haben. Ich musste die VM neu starten und ./launcher start app ausführen, um die Foren zu starten. Als Discourse jedoch wieder online war, blieb die Discourse-Version bei der vorherigen Version 3.3.0.beta4-dev.

Ich kann das Ubuntu-Upgrade heute nicht durchführen, halte aber alle auf dem Laufenden, wenn ich es kann und ob der Wiederaufbau dann erfolgreich ist.

Ich habe unsere Entwicklungsinstanz heute auf Ubuntu 20.6 aktualisiert und der Wiederaufbau/das Upgrade war erfolgreich auf Discourse 3.4.0.beta2-dev. Dies war jedoch der Host, der gestern auch ohne Probleme unter Ubuntu 18.4 wieder aufgebaut wurde.