Fortunatamente ho le precedenti immagini docker (spero), ma non sono sicuro di cosa fare per ripristinare i servizi. Uso anche DigitalOcean.
Errore
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle install --retry 3 --jobs 4' è fallito con ritorno #<Process::Status: pid 448 exit 5>
Posizione del fallimento: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec fallito con i parametri {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle config --local deployment true'", "su discourse -c 'bundle config --local without \\\"development test\\\"'", "su discourse -c 'bundle install --retry 3 --jobs 4'\"]}}
bootstrap fallito con codice di uscita 5
** FAILED TO BOOTSTRAP ** 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.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261
Mentre ho ancora le vecchie immagini, ho rimosso l’immagine più recente…
docker rmi 51421f454322 -f
Ho ancora i vecchi container, ma quando provo a eseguire ./launcher start app, sembra preferire quell’immagine eliminata.
root@hostname:/var/discourse# ./launcher start app
WARNING: Docker version 17.05.0-ce deprecated, recommend upgrade to 17.06.2 or newer.
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
starting up existing container
+ /usr/bin/docker start app
app
root@hostname:/var/discourse# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
afeec2777503 51421f454322 \"/sbin/boot\" 3 hours ago Up 5 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp app
root@hostname:/var/discourse# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
discourse/base 2.0.20231218-0429 984f729957df 12 days ago 3.14GB
C’è un modo per procedere con l’image id 984f729957df?
La cosa più semplice è procedere e avviare un nuovo droplet e copiare /var/discourse su di esso e ricostruire lì. Questo risolverà il problema piuttosto che mitigarne gli effetti.
Esiste un comando di avvio che ti fornirà il comando docker che potrebbe essere d’aiuto. Puoi guardare lo script di avvio per trovarne il nome (ma sono al telefono).
Sembra che tu stia suggerendo: ./launcher start-cmd app
Emette parecchio, iniziando con + true run --shm-size=512m -d --restart=always...
Mi sono sbilanciato e ho provato: docker + true run 984f729957df --shm-size=512m -d --restart=always ... senza successo.
container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH".
Qualsiasi aiuto tu possa fornire è benvenuto. Grazie.
Grazie per il suggerimento. Non sono un fan delle migrazioni non pianificate, ma sembra che sia in programma. Presumo che ti riferisca a questo? Move a Discourse site to another VPS with rsync
Ci saranno istruzioni aggiuntive se abbiamo abilitato DO Spaces (archiviazione S3)?
Considerato il periodo dell’anno, sarà molto difficile (leggi: probabilmente impossibile) coordinare gli altri per le modifiche necessarie in modo tempestivo.
Preferirei piuttosto tornare allo stato in cui funzionava l’ultima volta in modo da poter pianificare una migrazione, invece.
Spostarsi su un nuovo droplet è a basso rischio poiché puoi semplicemente ripristinare il DNS al tuo sito disabilitato, ma se non hai accesso al DNS e a Digital Ocean sei bloccato.
Sembra che tu abbia dimenticato di quotare qualcosa con il comando start. Sembra che questo sia ciò che vuoi fare.
Se lo sincronizzi con rsync, dovresti stare bene. Poi puoi passare alla configurazione consigliata. Potresti avere problemi se provi un ripristino del database.
Grazie ancora per il tuo aiuto. Per quanto riguarda rsync, sono un po’ preoccupato per come le istruzioni indicano in così tante parole:
imposta il nuovo server e sincronizza
interrompi il servizio sul vecchio server
sincronizza di nuovo ma con --delete
Ciò sembra volatile e anche non possibile nel mio scenario. Sarà una preoccupazione? Penso che si tratti solo di assicurarsi che tutto ciò che è successo dall’ultima sincronizzazione rsync sul forum venga sincronizzato, ma potrei sbagliarmi.
Aggiornamento:
Siamo di nuovo online con un Droplet completamente nuovo.
Sono contento di sapere ora che una migrazione è relativamente semplice. Sarebbe stato molto meglio se l’aggiornamento non avesse compromesso il vecchio droplet.
So che è una festività, ma sarebbe fantastico se qualcuno del team di sviluppo potesse dedicare del tempo a esaminare la questione. Non credo che questo sia un caso isolato. Sono stato taggato in un altro thread dove si sta accumulando una serie di problemi.