Solange diese hinzugefügten Plugins nicht standardmäßig aktiviert sind, zumindest nicht für bestehende Instanzen, ist alles in Ordnung. Aber was die Änderungen an den Gem-Abhängigkeiten und die mehrfachen Datenbankmigrationsfehler, mit denen wir konfrontiert waren, betrifft, mache ich mir etwas Sorgen, dass etwas unsichtbar kaputt oder verloren gegangen sein könnte. Leider macht der Rebuild in dieser Hinsicht keine Protokolle, er sagt nur, dass cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' mit Fehlercode beendet wurde, aber keine Details, auch nicht in den Protokollen .
das klingt seltsam, läuft PG in einem separaten Container, ist pgvector installiert?
Generell, wenn etwas fehlschlägt, kann man ein Stück nach oben scrollen und den Fehler finden, aufgrund der Reihenfolge liegt der Fehler oft 100 Zeilen weiter oben.
Nur der eigenständige Discourse Docker-Container. Außerdem war ich nicht ganz korrekt, tatsächlich gibt es noch mehr Ausgaben dazu, aber nichts, womit ich genug Sinn machen konnte:
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1454:in `migrate' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1261:in `up’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/migration.rb:1236:in `migrate' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.2/lib/active_record/tasks/database_tasks.rb:270:in `migrate’
/var/www/discourse/lib/tasks/db.rake:267:in `block (2 levels) in <main>’ /var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' /var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize’
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize' /var/www/discourse/lib/tasks/db.rake:242:in `block in ’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.0/exe/rake:27:in `<top (required)>' /usr/local/bin/bundle:25:in `load’
/usr/local/bin/bundle:25:in `’
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2025-07-29T20:36:15.074727 #1] INFO – : == 20180828095129 PushFixTopicEmbedAuthorsJob: migrating ==========
== 20180828095129 PushFixTopicEmbedAuthorsJob: migrated (0.0021s) =============
I, [2025-07-29T20:36:15.075331 #1] INFO – : Terminating async processes
I, [2025-07-29T20:36:15.075355 #1] INFO – : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 45
I, [2025-07-29T20:36:15.075376 #1] INFO – : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 112
2025-07-29 20:36:15.075 UTC [45] LOG: received fast shutdown request
112:signal-handler (1753821375) Received SIGTERM scheduling shutdown…
2025-07-29 20:36:15.091 UTC [45] LOG: aborting any active transactions
2025-07-29 20:36:15.092 UTC [45] LOG: background worker “logical replication launcher” (PID 59) exited with exit code 1
2025-07-29 20:36:15.092 UTC [54] LOG: shutting down
2025-07-29 20:36:15.105 UTC [54] LOG: checkpoint starting: shutdown immediate
112:M 29 Jul 2025 20:36:15.125 # User requested shutdown…
112:M 29 Jul 2025 20:36:15.125 * Saving the final RDB snapshot before exiting.
112:M 29 Jul 2025 20:36:15.247 * DB saved on disk
112:M 29 Jul 2025 20:36:15.247 # Redis is now ready to exit, bye bye…
2025-07-29 20:36:15.273 UTC [54] LOG: checkpoint complete: wrote 10 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.066 s, sync=0.046 s, total=0.181 s; sync files=9, longest=0.026 s, average=0.006 s; distance=36 kB, estimate=36 kB
2025-07-29 20:36:15.276 UTC [45] LOG: database system is shut down
## FAILED
Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 635 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn’
`exec failed with the params {“cd”=>“$home”, “tag”=>“migrate”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}’
`bootstrap failed with exit code 1`
`** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.`
`./discourse-doctor may help diagnose the problem.`
Übrigens, hier stimmt etwas mit den Codeblöcken und Zäunen nicht. Weder das manuelle Hinzufügen von Backticks funktioniert, noch das Auswählen mehrerer Zeilen und das Drücken der Code-Schaltfläche im Editor. Es werden Teile in Code umgewandelt, die gar nicht ausgewählt wurden.
Es hat also versucht, ein Plugin zu migrieren, das vorher nicht vorhanden und nicht aktiviert war? Irgendeine Idee, warum es nach mehreren Wiederaufbauversuchen erfolgreich war?
Ich bin etwas verwirrt, warum es fehlgeschlagen ist, aber ich sehe das Problem hier, wir rufen Anwendungscode aus einer Migration auf, was sehr fehleranfällig ist.
Ja, wie gesagt, nach mehreren Wiederaufbauversuchen hat es endlich geklappt. Im letzten erfolgreichen Log sehe ich diese spezielle Migration überhaupt nicht mehr. Wahrscheinlich wurde sie trotz des Fehlers als „migriert“ markiert und daher beim nächsten Wiederaufbau einfach nicht mehr versucht?
Die Migration hat gerade einen Schlüssel auf Redis gesetzt. Ein möglicher Grund für das Fehlschlagen ist, dass der Code für das RSS-Plugin aus irgendeinem Grund nicht geladen wurde. Wir werden dies nachverfolgen, damit andere Personen dies nicht erleben.
.
.