Mi chiedo se possa risolvere questo problema svuotando Redis o aggiornandolo; non è stato toccato per gli ultimi 8+ mesi. Non ho mai gestito Redis personalmente, ma la nostra istanza Tests-Pass di Discourse è stata configurata utilizzando local_discourse invece di Discourse Docker, che ora è raccomandato su questo forum. I problemi che sto riscontrando sono relativi alla mancata invio di email agli utenti. Qualsiasi aiuto o suggerimento è apprezzato!
Sidekiq non è in esecuzione. Molti compiti, come l’invio di email, vengono eseguiti in modo asincrono da Sidekiq. Assicurati che almeno un processo Sidekiq sia in esecuzione.
Il test del battito cardiaco di Sidekiq è fallito, riavvio in corso
Sarebbe utile per me utilizzare launcher per ricostruire o riavviare il container redis?
Utilizzo: launcher COMANDO CONFIG [–skip-prereqs] [–docker-args STRING]
Comandi:
start: Avvia/inizializza un container
stop: Ferma un container in esecuzione
restart: Riavvia un container
destroy: Ferma e rimuove un container
enter: Apre una shell per eseguire comandi all’interno del container
logs: Visualizza i log Docker di un container
bootstrap: Inizializza un container per la configurazione basata su un modello
run: Esegue il comando specificato con la configurazione nel contesto dell’ultima immagine inizializzata
rebuild: Ricostruisce un container (distrugge quello vecchio, inizializza, avvia uno nuovo)
cleanup: Rimuove tutti i container fermi da oltre 24 ore
start-cmd: Genera il comando Docker utilizzato per avviare il container
Opzioni:
–skip-prereqs Non verificare i prerequisiti di launcher
–docker-args Argomenti aggiuntivi da passare durante l’esecuzione di Docker
–skip-mac-address Non assegnare un indirizzo MAC
–run-image Sostituisci l’immagine utilizzata per l’esecuzione del container
Hai installato seguendo la guida Installazione Standard Ufficiale di Discourse o in qualche altro modo? Se hai un’installazione standard, sì, eseguire ./launcher rebuild app risolverà probabilmente il tuo problema.
Non ancora, ma stiamo fissando un orario per la migrazione. Il nostro Discourse è in funzione da quasi tre anni e non voglio aggiungere tempi di inattività non necessari. La nostra istanza è gestita interamente da volontari, quindi nell’ultimo mese ho imparato da solo a mantenerla. Se una rapida correzione per Redis può aiutare (quel container è attivo da un anno senza modifiche), vorrei applicarla.
Se non hai eseguito un’installazione standard all’inizio, è impossibile sapere cosa possa risolvere il tuo problema attuale.
Ti consiglio di configurare una nuova macchina virtuale ed eseguire lì un’installazione di prova per verificare che funzioni. Durante il trasferimento, puoi impostare il vecchio forum in modalità sola lettura, eseguire un backup, ripristinarlo sulla nuova macchina virtuale e modificare il DNS con quasi zero tempi di inattività. (Ci sarà comunque un breve intervallo, poiché dovrai ricostruire dopo aver modificato il DNS per installare il certificato Let’s Encrypt)
Grazie, Let’s Encrypt dovrebbe essere piuttosto semplice, dato che è stato configurato come una semplice modifica al reverse proxy nginx. Bene saperlo, e ci aspettiamo che ci sarà un po’ di downtime. Bisogna solo programmarlo in un orario di minor affluenza.
Sto per migrare e ripristinare il backup nelle immagini ufficiali. C’è qualcosa che dovrei sapere riguardo alla cancellazione delle email salvate, ecc., che potrebbero inviare spam agli utenti una volta che Sidekiq, ecc., funzionerà correttamente. Grazie!
Quindi, stiamo cercando di seguire la documentazione per l’installazione delle immagini Docker ufficiali di Discourse, ma stiamo incontrando problemi. Abbiamo concluso che ci manca il container redis, il container mail-receiver e il container data che avevamo precedentemente in Docker.
Sembra che la nostra installazione precedente includa: app.yml data.yml mail-receiver.yml redis.yml
Questa configurazione multi-container differisce dalle istruzioni di installazione di base. Ho un backup della nostra vecchia directory /var/discourse a cui fare riferimento.
FAILED │················································································································
-------------------- │················································································································
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' fallito con codice di ritorno #<Process::Status: pid 645 exit 1> │················································································································
Posizione dell'errore: /pups/lib/pups/exec_command.rb:112:in `spawn' │················································································································
esecuzione fallita con i parametri {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]} │················································································································
bbf0e57ac69f1febe2a5f149aa7e6e12541c3c23aaf199188fdf19d507254b58 │················································································································
** BOOTSTRAP FALLITO ** si prega di scorrere verso l'alto e cercare messaggi di errore precedenti, potrebbero essercene più di uno. │················································································································
./discourse-doctor potrebbe aiutare a diagnosticare il problema.
Sembra che abbiamo saltato il passaggio ./launcher bootstrap data ./launcher start redis
[Mon 11 May 2020 12:53:20 AM UTC] Esecuzione comando reload: sv reload nginx │················································································································
fail: nginx: runsv non in esecuzione │················································································································
[Mon 11 May 2020 12:53:20 AM UTC] Errore di reload per : │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Dominii non modificati. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Salta, prossimo tempo di rinnovo: Thu 09 Jul 2020 11:33:04 PM UTC │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Aggiungi '--force' per forzare il rinnovo. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Installazione chiave in:/shared/ssl/discuss.noisebridge.info_ecc.key │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Installazione catena completa in:/shared/ssl/discuss.noisebridge.info_ecc.cer │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Esecuzione comando reload: sv reload nginx │················································································································
fail: nginx: runsv non in esecuzione │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Errore di reload per : │················································································································
run-parts: esecuzione di /etc/runit/1.d/remove-old-socket │················································································································
Avviato runsvdir, PID è 626 │················································································································
ok: run: redis: (pid 636) 0s │················································································································
chgrp: gruppo non valido: 'syslog' │················································································································
ok: run: postgres: (pid 639) 0s │················································································································
rsyslogd: imklog: impossibile aprire il log del kernel (/proc/kmsg): Operazione non consentita. │················································································································
rsyslogd: attivazione del modulo imklog fallita [v8.1901.0 prova https://www.rsyslog.com/e/2145 ] │················································································································
supervisor pid: 640 unicorn pid: 667
È corretto, gli importatori lo hanno impostato in modo che tu non invii 50.000 email dopo una migrazione. Attiva l’email con cura nelle impostazioni del tuo sito.
La nostra istanza è gestita interamente da volontari, quindi nell’ultimo mese ho imparato da solo a mantenerla. Se una rapida correzione per Redis può aiutare (quel container è attivo da un anno senza modifiche), vorrei applicarla.