Ciao, ho due grossi problemi quando arresto e riavvio Discourse.
Primo
Dopo 2 o 3 volte che lo faccio (indipendentemente dal fatto che usi ./launcher stop o lo arresti tramite Portainer), il contenitore si rifiuta di riavviarsi, rimanendo bloccato su “rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory”. (Ho appena notato che il socket non si trova nella directory “shared”, bensì in “shared/standalone”; è solo un errore nel messaggio?)
Per ragioni a me ancora sconosciute, questo socket, forse dopo lo stop, diventa una directory, e il template non riesce a eliminarlo perché tenta di cancellare una directory invece di un socket. Eliminarlo manualmente non cambia nulla: ricompare ogni volta.
Secondo
“./launcher rebuild app” si blocca su “FATAL: the database system is starting up”, dopo il primo “PANIC could not locate a valid checkpoint record”. Ho letto e provato tutto ciò che ho trovato riguardo a questo problema, e l’unica “soluzione” funzionante che ho individuato è stata cancellare la directory di Discourse con tutto il suo contenuto e ricominciare da capo con la configurazione… ovviamente non è una vera soluzione!
Sembra che a volte l’arresto del contenitore Discourse lasci il database in uno stato compromesso, impedendogli di procedere perché “è in fase di avvio”, forse mentre tenta di correggere qualcosa. Tuttavia, non ho ancora capito come risolvere questo problema, che sembra manifestarsi dopo alcuni arresti e riavvii.
Qualche indizio? Esiste un modo per permettere a Postgres di risolvere i suoi problemi?
No, non è un errore. Questo file si trova nel volume montato nel contenitore, quindi ha percorsi diversi a seconda del punto di vista, ovvero all’interno del contenitore rispetto a quello esterno.
Ciò accade quando il contenitore non viene arrestato correttamente. PostgreSQL ha bisogno di tempo per spegnersi correttamente, e noi gestiamo questo processo quando si utilizza il nostro comando di arresto tramite il launcher. Tuttavia, se la tua istanza è di dimensioni sufficientemente grandi o ci sono troppe transazioni in esecuzione, il database potrebbe avere difficoltà a fermarsi correttamente entro il tempo limite assegnato.
Tuttavia, ho notato che anche nel file system dell’host, in “shared/standalone”, viene creato il file “nginx.http.sock”. Inizialmente è rosa, come un socket, ma dopo un po’, forse dopo uno stop, diventa blu, come una directory, e il contenitore si rifiuta di avviarsi, bloccato nel tentativo di eliminare un socket che è diventato una directory.
Quindi, cosa possiamo fare per risolvere il problema? Fino ad ora ho solo fatto esperimenti, ma se dovessi andare online con alcune centinaia di persone connesse e centinaia di migliaia di post, rischio di perdere tutto solo perché Postgres non gestisce un’interruzione improvvisa? Dovrò fare qualcosa per riparare un database danneggiato. Discourse può essere eseguito su un database PostgreSQL esterno, qualcosa che possiamo gestire se il contenitore Discourse non si avvia? In breve, in caso di “PANIC” o “FATAL”, dovrebbe esserci una soluzione…
Sto effettivamente cercando di risolvere il problema (per il futuro) configurando un Postgres “containerizzato” e collegandolo a Discourse, nella speranza di non danneggiare il database (o almeno di poter eseguire alcune operazioni di manutenzione anche quando Discourse è spento) quando si arresta Discourse.