PostgreSQL Bloccato durante la ricostruzione

Installazione
1

Ciao a tutti,

Sto riscontrando un problema con l’avvio di PostgreSQL quando ho provato a ricostruire la mia app e spero di ricevere aiuto.

Ecco il log, è bloccato in questo stato da più di 30 minuti.

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

Quindi non si è spento correttamente e ha cercato di correggere le cose, e pensa di averlo fatto.

Forse interrompilo con control-c e vedi se riesci a eseguire ./launcher start app per riavviare il vecchio container.

Se funziona, puoi riprovare a eseguire ./launcher stop app e poi ricostruire.

3 Mi Piace
3

Sto riscontrando lo stesso problema cercando di ricostruire negli ultimi giorni. Non riesco a far funzionare o ricostruire Discourse senza problemi.

Ho provato a utilizzare la funzionalità di avvio/arresto e non sembrava funzionare. Anche la VM stessa è stata riavviata un paio di volte. Continua a bloccarsi su quella riga riguardo al database pronto ad accettare connessioni.

4

Control-C non ha funzionato e ho provato molte cose diverse, incluso il ripristino a vecchie versioni, ma non appena ho provato la ricostruzione, si è bloccato nello stesso identico punto.

5

Quanta RAM hai? La tua connessione di rete è lenta?

6

per il mio problema… un sacco di RAM… 8 GB. La rete va bene

7

4 GB di RAM, ho controllato la rete, l’utilizzo del disco, l’utilizzo della CPU, l’utilizzo della RAM, tutto sembra a posto.

8

Ho fatto più progressi. In /var/discourse/ sul mio server, ho effettuato il checkout del commit b1108913820edd27f869634d0fc654639758889a. Questo commit è di qualche giorno fa e non ha questi tre commit (1, 2, 3 nella cronologia di discourse_docker. Sospetto che una di queste modifiche sia la causa del problema di hanging di postgres.

Comunque, ho finalmente riavviato l’app. È stata un’esperienza terribile lol

3 Mi Piace
11

Stesso problema qui durante l’aggiornamento da 3.3.0 a 3.3.1. L’aggiornamento si blocca sulla stessa riga di log (il sistema di database è pronto ad accettare connessioni).

Il riavvio aiuta o semplicemente l’interruzione del processo di aggiornamento e l’esecuzione di ./launcher start app. Viene mostrata la nuova versione 3.3.1. Ma non sono sicuro che questa sia una procedura sensata.

13

Quindi ci sono quattro persone con un problema, credo.

Coloro che hanno avuto problemi erano su ARM o su Intel?

1 Mi Piace
14

Questa è un’ottima domanda.

Ho appena eseguito una nuova installazione su una nuova VM di Digital Ocean e poi ho eseguito una ricompilazione e ha funzionato perfettamente.

15

Sto usando Intel.

Il modo in cui ho risolto il problema è stato avviare una nuova istanza e fare un’installazione pulita, ripristinare il backup, quindi la ricostruzione funziona correttamente.

Ho anche un backup di una versione funzionante (che è su una versione leggermente precedente), ma non appena sono passato all’ultima versione tramite ricostruzione, ho riscontrato lo stesso problema, quindi sospetto che ci sia qualcosa introdotto con un commit recente e che interrompa solo l’aggiornamento dalla vecchia alla nuova versione.

1 Mi Piace
16

Dannazione.

Hmm. Vedrò se ho un sito che non mi interessa se va giù.

Suppongo che tu abbia una normale installazione standard a 1 container. Vedrò se riesco a trovarne una.

17

Sto solo riproponendo questo perché ho anche riscontrato questo problema dopo il commit di cui sopra. Ho provato tutto quanto sopra anche per risolvere il problema.

2 Mi Piace
18

x86. Sono su ubuntu bionic per il sistema operativo host… forse questo è di conseguenza. Non sono sicuro di quale sia il sistema operativo degli altri

19

È passato più di un anno dalla fine del supporto (EOL). https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices.

Non è troppo presto per creare una nuova VM e migrare lì.

4 Mi Piace
20

Solo ulteriori informazioni per aiutare a indagare sul problema.

Sto riscontrando questo su un host che esegue Ubuntu 18.04.6, ma un altro host è stato aggiornato oggi con la stessa versione di Ubuntu e la ricostruzione di Discourse è progredita normalmente.

Aggiornerò Ubuntu sull’host interessato e vedrò se questo aiuta. Terrò tutti aggiornati.

2 Mi Piace
21

Per coloro che sono interessati, è possibile eseguire il comando ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" e comunicarmi se l’output differisce da quello sottostante?

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 Mi Piace
22 
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dec 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 Mi Piace
23

Output dalla VM che riscontra problemi di ricompilazione:

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

Solo una nota, qualcosa di leggermente diverso nel mio caso.
La ricompilazione si è bloccata su “Il sistema di database è pronto ad accettare connessioni” come altri hanno riscontrato. Ho dovuto riavviare la VM ed eseguire ./launcher start app per avviare i Forum. Tuttavia, quando Discourse è tornato online, la versione di Discourse è rimasta alla versione precedente 3.3.0.beta4-dev.

Non sono in grado di eseguire l’aggiornamento di Ubuntu oggi, ma terrò tutti aggiornati quando potrò e se la ricompilazione avrà successo.

Ho aggiornato la nostra istanza di sviluppo a Ubuntu 20.6 oggi e la ricompilazione/aggiornamento è riuscita a Discourse 3.4.0.beta2-dev. Tuttavia, questo era l’host che si è ricompilato senza problemi anche su Ubuntu 18.4 ieri.