Ciao a tutti – sono nuovo su Discourse (sembra fantastico!) e, anche se ho alcune competenze tecniche di base, direi che mi considero un principiante nel mondo di Docker e delle macchine virtuali Linux.
Sto ricevendo costantemente il messaggio di errore riportato di seguito… ho provato a eseguire discourse doctor, ma senza successo. Spero che qualcuno possa indicarmi la strada giusta per capire cosa sta succedendo. Grazie mille in anticipo! – Tim
[2021-06-11T04:09:29.733935 #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, [2021-06-11T04:09:29.735773 #1] INFO -- : > sleep 5
2021-06-11 04:09:30.320 GMT [54] LOG: 0 8kB è al di fuori dell'intervallo valido per il parametro "shared_buffers" (16 .. 1073741823)
2021-06-11 04:09:30.322 UTC [54] FATAL: il file di configurazione "/etc/postgresql/13/main/postgresql.conf" contiene errori
I, [2021-06-11T04:09:34.739847 #1] INFO -- :
I, [2021-06-11T04:09:34.740097 #1] INFO -- : > su postgres -c 'createdb discourse' || true
createdb: errore: impossibile connettersi al database template1: impossibile connettersi al server: Nessun file o directory
È il server in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:34.860266 #1] INFO -- :
I, [2021-06-11T04:09:34.860745 #1] INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: errore: impossibile connettersi al server: Nessun file o directory
È il server in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.023426 #1] INFO -- :
I, [2021-06-11T04:09:35.023810 #1] INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: errore: impossibile connettersi al server: Nessun file o directory
È il server in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.137806 #1] INFO -- :
I, [2021-06-11T04:09:35.138325 #1] INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: errore: impossibile connettersi al server: Nessun file o directory
È il server in esecuzione localmente e accetta
connessioni sul socket di dominio Unix "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.257190 #1] INFO -- :
I, [2021-06-11T04:09:35.257476 #1] INFO -- : Terminazione dei processi asincroni
FALLITO
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' fallito con codice di uscita #<Process::Status: pid 80 exit 2>
Posizione dell'errore: /pups/lib/pups/exec_command.rb:112:in `spawn'
esecuzione fallita con i parametri "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
14ef6216494c846091ea6ce48143e2f25018b9d2579b6d4d0021d605f7f5e145
** BOOTSTRAP FALLITO ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti; potrebbero essercene più di uno.
Ciao @Meathead40,
sto riscontrando probabilmente lo stesso problema.
Sono riuscito a configurare Discourse su Oracle Free lo scorso giugno. Ora ho rieseguito lo script di configurazione per modificare alcune impostazioni relative alle email.
Il primo errore che riesco a rintracciare nel log è: FATAL: configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors,
ma nel mio caso quel file non esiste. Inoltre, il servizio PostgreSQL non è in esecuzione (anzi, non è nemmeno disponibile come servizio).
Sei riuscito a risolvere questo problema? Qualcun altro ha riscontrato la stessa cosa?
Grazie per i suggerimenti. Sono riuscito a raccogliere più informazioni.
Questo è tratto dal log, intorno al momento dell’errore (i messaggi precedenti sono di giorni prima):
2021-08-02 13:33:16.980 UTC [2419] LOG: received smart shutdown request
2021-08-02 13:33:28.273 UTC [2419] LOG: background worker "logical replication launcher" (PID 2442) exited with exit code 1
2021-08-02 13:33:28.344 UTC [2437] LOG: shutting down
2021-08-02 13:33:28.552 UTC [2419] LOG: database system is shut down
Ho anche ottenuto la configurazione del buffer condiviso:
shared_buffers = 128MB # min 128kB
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
Sto eseguendo la configurazione su un’installazione esistente per modificare alcuni parametri di configurazione. La prima parte dello script rileva quanto segue:
sudo ./discourse-setup
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
The configuration file containers/app.yml already exists!
. . . reconfiguring . . .
Saving old file as app.yml.2021-08-03-102829.bak
Stopping existing container in 5 seconds or Control-C to cancel.
+ /bin/docker stop -t 30 app
app
Found 0GB of memory and 1 physical CPU cores
setting db_shared_buffers = 0MB
setting UNICORN_WORKERS = 0
containers/app.yml memory parameters updated.
Continuando, vengono passati tutti i parametri di configurazione e infine si procede alla compilazione… questo dovrebbe essere il indizio che stavi cercando
2021-08-03 10:30:37.709 GMT [55] LOG: 0 8kB is outside the valid range for parameter "shared_buffers" (16 .. 1073741823)
2021-08-03 10:30:37.713 UTC [55] FATAL: configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors
Non è un buon segno! Quel numero dovrebbe provenire direttamente dall’output di
free -g --si | awk ' /Mem:/ {print $2} '
Stà riportando 703 MByte, che è (ufficialmente) troppo basso per far funzionare bene Discourse. Se vuoi correre rischi (e non avere supporto!) puoi modificare il numero magico 990 in
Penso che tu abbia bisogno di un’istanza più grande con più RAM.
Il file di configurazione ha ancora il controllo disabilitato, ma penso che venga sovrascritto? Proverò a modificare il valore come hai indicato e riferirò cosa succede.
Sono riuscito a completare la configurazione e la ricostruzione. I passaggi seguiti sono stati:
commentare il controllo della memoria (#check_disk_and_memory) in /var/discourse/discourse-setup (non sono sicuro che sia necessario)
eseguire il comando sudo ./discourse-setup dalla cartella /var/discourse (questo genererà il file /var/discourse/containers/app.yml e tenterà di procedere con la ricostruzione, che fallirà come descritto sopra)
modificare app.yml per impostare esplicitamente db_shared_buffers: “128MB” e UNICORN_WORKERS: 1
avviare una ricostruzione con sudo ./launcher rebuild app (dalla cartella /var/discourse)
So che questo è al limite dei requisiti, ma terrò sotto controllo il comportamento dell’istanza.
Sono contento che tu abbia risolto. Nel thread collegato e in quello a cui si fa riferimento qui, mi sembra molto preferibile cambiare il numero “magic forgiveness” di 990 con il valore che rappresenta il tuo sistema. “Disabilitare il controllo della memoria” sta effettivamente causando problemi.
È chiaro che il team di Discourse debba stabilire un limite inferiore di un certo valore, per tracciare una linea tra configurazioni supportate e non supportate, e lo hanno fissato formalmente a 1G, con un’agevolazione a 990. Ma 960 mi sembra abbastanza vicino a 990 e nasce per motivi simili. D’altra parte, 703 sembra molto diverso!
Ciao Ed,
sono d’accordo, cambierò il numero. Sono piuttosto sorpreso da una quantità di memoria così bassa. Le specifiche dell’istanza Oracle (Free tier) indicano 1 GB di memoria, eppure la versione gratuita ne offre solo circa il 60-70%. Sono un po’ confuso e non conosco il motivo di ciò.
Forse l’istruzione più importante mancante è non usare l’immagine server predefinita. Discourse richiede 1 GB di RAM (o circa) e l’immagine Oracle Linux non lascia abbastanza memoria per qualche motivo. Non so se CentOS funzionerà, ma l’immagine Ubuntu va bene. Assicurati solo di scegliere l’installazione completa2 invece di quella “Minimal”.
Sospetto che la versione predefinita di Oracle Linux includa una serie di componenti non necessari per l’installazione di Discourse. Immagino che il suo caso d’uso principale sia l’hosting di server di database Oracle. Fortunatamente, l’immagine Ubuntu funziona perfettamente. Il mio sito di test/host per commenti è ancora attivo. (Non c’è molta attività, però.)
Fortunatamente, l’immagine Ubuntu funziona perfettamente. Il mio