Absturz nach Versuch, ein Update durchzuführen

[TroLLoBlogger]

Nach dem Versuch, Discourse über das Admin-Panel zu aktualisieren, ist der Prozess abgestürzt und mein Forum ließ sich nicht mehr laden. Glücklicherweise gibt es eine Lösung für das Problem

Öffnen Sie ein Terminal auf Ihrem Server und führen Sie dann die folgenden Befehle aus:

cd /var/discourse

./launcher rebuild app

Nachdem der Neuaufbau abgeschlossen war, lief bei mir alles wieder normal und das Forum wurde aktualisiert. Ich hinterlasse auch ein Protokoll des Fehlers, der das Problem verursacht hat, da er mit einem Discourse-Plugin zusammenhängt.

LOG

Kompilieren von 46 Plugins…
rake aborted!
AssetProcessor::TimeoutError: [PLUGIN discourse-doc-categories] Skript abgebrochen: Timeout nach 120s (AssetProcessor::TimeoutError)
/var/www/discourse/lib/plugin/js_compiler.rb:32 ‘Plugin::JsCompiler#compile!’
/var/www/discourse/lib/plugin/js_manager.rb:136 ‘Plugin::JsManager#compile_js_bundle’
/var/www/discourse/lib/plugin/js_manager.rb:57 ‘block in Plugin::JsManager#compile!’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:689 ‘Parallel.call_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:659 ‘Parallel.process_incoming_jobs’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:638 ‘block in Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Process.fork’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:619 ‘block in Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Array#each’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Enumerable#each_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:557 ‘Parallel.work_in_processes’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:304 ‘Parallel.map’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:248 ‘Parallel.each’
/var/www/discourse/lib/plugin/js_manager.rb:56 ‘Plugin::JsManager#compile!’
/var/www/discourse/lib/tasks/assets.rake:27 'block in ’

Ursache:
AssetProcessor::TimeoutError: Skript abgebrochen: Timeout nach 120s (AssetProcessor::TimeoutError)
/var/www/discourse/lib/asset_processor.rb:185 ‘MiniRacer::Context#call’
/var/www/discourse/lib/asset_processor.rb:185 ‘block in AssetProcessor.v8_call’
/var/www/discourse/lib/asset_processor.rb:184 ‘Thread::Mutex#synchronize’
/var/www/discourse/lib/asset_processor.rb:184 ‘AssetProcessor.v8_call’
/var/www/discourse/lib/asset_processor.rb:264 ‘AssetProcessor#rollup’
/var/www/discourse/lib/plugin/js_compiler.rb:21 ‘Plugin::JsCompiler#compile!’
/var/www/discourse/lib/plugin/js_manager.rb:136 ‘Plugin::JsManager#compile_js_bundle’
/var/www/discourse/lib/plugin/js_manager.rb:57 ‘block in Plugin::JsManager#compile!’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:689 ‘Parallel.call_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:659 ‘Parallel.process_incoming_jobs’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:638 ‘block in Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Process.fork’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:619 ‘block in Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Array#each’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Enumerable#each_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:557 ‘Parallel.work_in_processes’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:304 ‘Parallel.map’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:248 ‘Parallel.each’
/var/www/discourse/lib/plugin/js_manager.rb:56 ‘Plugin::JsManager#compile!’
/var/www/discourse/lib/tasks/assets.rake:27 'block in ’

Ursache:
MiniRacer::ScriptTerminatedError: abgebrochen (MiniRacer::ScriptTerminatedError)
/var/www/discourse/lib/asset_processor.rb:185 ‘MiniRacer::Context#call’
/var/www/discourse/lib/asset_processor.rb:185 ‘block in AssetProcessor.v8_call’
/var/www/discourse/lib/asset_processor.rb:184 ‘Thread::Mutex#synchronize’
/var/www/discourse/lib/asset_processor.rb:184 ‘AssetProcessor.v8_call’
/var/www/discourse/lib/asset_processor.rb:264 ‘AssetProcessor#rollup’
/var/www/discourse/lib/plugin/js_compiler.rb:21 ‘Plugin::JsCompiler#compile!’
/var/www/discourse/lib/plugin/js_manager.rb:136 ‘Plugin::JsManager#compile_js_bundle’
/var/www/discourse/lib/plugin/js_manager.rb:57 ‘block in Plugin::JsManager#compile!’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:689 ‘Parallel.call_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:659 ‘Parallel.process_incoming_jobs’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:638 ‘block in Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Process.fork’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:629 ‘Parallel.worker’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:619 ‘block in Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Array#each’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Enumerable#each_with_index’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:618 ‘Parallel.create_workers’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:557 ‘Parallel.work_in_processes’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:304 ‘Parallel.map’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/parallel-2.1.0/lib/parallel.rb:248 ‘Parallel.each’
/var/www/discourse/lib/plugin/js_manager.rb:56 ‘Plugin::JsManager#compile!’
/var/www/discourse/lib/tasks/assets.rake:27 'block in ’

Aufgaben: TOP => assets:precompile
(Vollständige Trace-Ausgabe erhalten Sie durch Ausführen der Aufgabe mit --trace)
/var/www/discourse/script/assemble_ember_build.rb:167 ‘Kernel#system’: Befehl fehlgeschlagen mit Exit-Code 1: bin/rake (RuntimeError)
von /var/www/discourse/script/assemble_ember_build.rb:167 ‘’
Docker Manager: UPGRADING FEHLGESCHLAGEN
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:205 ‘DockerManager::Upgrader#run’
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:105 ‘DockerManager::Upgrader#upgrade’
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19 'block in ’
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6 ‘Kernel#fork’
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6 ‘’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/commands/runner/runner_command.rb:44 ‘Kernel.load’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/commands/runner/runner_command.rb:44 ‘block in Rails::Command::RunnerCommand#perform’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/activesupport-8.0.5/lib/active_support/execution_wrapper.rb:91 ‘ActiveSupport::ExecutionWrapper.wrap’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/commands/runner/runner_command.rb:70 ‘Rails::Command::RunnerCommand#conditional_executor’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/commands/runner/runner_command.rb:43 ‘Rails::Command::RunnerCommand#perform’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor/command.rb:28 ‘Thor::Command#run’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor/invocation.rb:127 ‘Thor::Invocation#invoke_command’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/command/base.rb:178 ‘Rails::Command::Base#invoke_command’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/thor-1.5.0/lib/thor.rb:538 ‘Thor.dispatch’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/command/base.rb:73 ‘Rails::Command::Base.perform’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/command.rb:65 ‘block in Rails::Command.invoke’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/command.rb:143 ‘Rails::Command.with_argv’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/command.rb:63 ‘Rails::Command.invoke’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/railties-8.0.5/lib/rails/commands.rb:18 ‘’
/usr/local/lib/ruby/3.4.0/bundled_gems.rb:82 ‘Kernel.require’
/usr/local/lib/ruby/3.4.0/bundled_gems.rb:82 ‘block (2 levels) in Kernel#replace_require’
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/bootsnap-1.24.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33 ‘Kernel#require’
bin/rails:18 ‘’
Starten von 1 Pitchfork-Worker(s), die zunächst gestoppt waren

Wenn jemand in der Community immer noch Probleme mit dem Update hat, posten Sie bitte hier in den Kommentaren, und ich werde versuchen zu helfen.

Danke <3

[Lilly (Lillian)]

Deswegen aktualisiere ich nie über die Admin-Oberfläche

@TroLLoBlogger

Öffne ein Terminal auf deinem Server und führe dann folgende Befehle aus:

cd /var/discourse

./launcher rebuild app

Das ist der übliche Weg, um selbstgehostete Standardinstallationen zu aktualisieren.

[Falco]

Anscheinend war es ein bestimmtes Plugin, das innerhalb des 2-Minuten-Zeitlimits nicht erstellt werden konnte.

@TroLLoBlogger

PLUGIN discourse-doc-categories] Skript beendet: Timeout nach 120s

Könntest du deine Server-Spezifikationen teilen, @TroLLoBlogger?

[TroLLoBlogger]

Falls du etwas anderes meinst, sag mir Bescheid

[merefield (Robert)]

Aus Interesse: Haben Sie Swap konfiguriert?

Dieser einzelne vCPU könnte Ihnen schaden.

[TroLLoBlogger]

Ja, das ist möglich. Aber vor zwei Tagen gab es absolut keine Probleme mit dem Update. Ich werde auch einen 2-GB-Swap einrichten, und wir werden sehen

sudo fallocate -l 2G /swapfile        
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

[Falco]

Hmmm, ein einzelner vCPU-Kern könnte heutzutage zu schwach sein, um Web-Updates mit der Komplexität des Build-Prozesses für Frontend-Assets zu bewältigen.

Was meinst du, @david? Mit vorgefertigten Assets würde es problemlos funktionieren, aber wir müssten eventuell für diese Kombination die Web-Updates erkennen und deaktivieren…

[david (David Taylor)]

Vorgefertigte Assets sollten auch bei einem webbasierten Update eingebunden werden (sie werden separat vom Docker-Image verteilt).

doc-categories ist kein Kern-Plugin, daher stellen wir dafür keine Assets bereit. Aber… es ist ein sehr einfaches Plugin. 120 Sekunden sind eine sehr lange Zeit dafür, dass es so lange dauert

[Falco]

Ich weiß, was ich meine: Die Kombination aus

Nicht-Kern-Plugins + Installation mit nur einer vCPU

kann ein Fall sein, in dem der Benutzer zu einer Neupositionierung aufgefordert werden sollte.

[NateDhaliwal]

Ich habe einen Server mit 1 vCPU und 1 GB RAM. Ich habe es mindestens 10 Mal versucht, aber Discourse lief nie erfolgreich – außer einmal, doch dann musste ich es neu aufsetzen, was einen endlosen Fehlerzyklus auslöste. Ich habe 2 GB Swap eingerichtet, dann 5 GB, alles ohne Erfolg . Keine Plugins außer den Kernmodulen, einfach … gescheitert.

[TroLLoBlogger]

1 vCPU und 1 GB RAM – wenn ich mich nicht irre, ist das ein zu schwacher Server, insbesondere was den Arbeitsspeicher angeht. Mein Server hat zwar auch nur eine CPU, aber 4 GB RAM. Das ist bei externen Plugins zwar immer noch etwas knapp, aber ich werde es mir überlegen. Für den Moment kann SWAP für mich funktionieren; falls nicht, schalte ich die externen Plugins einfach ab, bis ich auf einen größeren Server umsteige.

[Falco]

Ja, der arme 1 vCPU-Prozess, der versucht, nginx, Ruby, PostgreSQL, Redis und Node.js für das Rebuild auszuführen, könnte einfach zu viel sein.

[Lilly (Lillian)]

FWIW: Ich betreibe eine Instanz mit 2 vCPUs, 4 GB RAM und 40 GB Festplattenspeicher und habe das Plugin discourse-doc-categories hinzugefügt, um den Build zu testen (ich habe zusätzlich zwei inoffizielle Plugins über den Kern-Plugins installiert):

               total        used        free      shared  buff/cache   available
Mem:           3.7Gi       1.6Gi        98Mi        69Mi       2.3Gi       2.2Gi
Swap:          2.0Gi        14Mi       2.0Gi

Wie auch immer, ich habe gerade das neueste (kritische) Update über die Admin-Oberfläche auf meinem iPhone durchgeführt – nur zum Spaß – und dieses Mal ging es schnell und problemlos.

[sniper756]

Nach einem Update über das Admin-Panel habe ich viele Anhänge verloren. Seitdem aktualisiere ich nicht mehr über das Admin-Panel, sondern verwende ausschließlich rebuild.

[merefield (Robert)]

Beide tun sehr Ähnliches und verändern weder den Seiteninhalt noch den Upload-Ordner. Das ist wirklich überraschend.

Der Hauptunterschied liegt in der Serverauslastung.