Job VacateLegacyPrefixBackups hängt fest

davidkingham · 7. Juni 2020 um 14:56

Diese Aufgabe läuft nach dem Update seit fast zwei Tagen. Ist das normal? Soll ich sie einfach in Sidekiq stoppen oder gibt es einen besseren Ansatz? Danke!

hostname	community-app
process_id	732
application_version	293467a37ae33c5fd8fd40bbfc05bffa578b90ed
current_db	default
current_hostname	community.naturephotographers.network
job	Jobs::VacateLegacyPrefixBackups
problem_db	default
time	8:28 am
	
opts	
current_site_id	default



aws-sdk-core-3.96.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/request.rb:70:in `send_request'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:59:in `block in vacate_legacy_prefix'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `each'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `vacate_legacy_prefix'
/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.2.2/lib/rails_multisite/connection_management.rb:68:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.7/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.7/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.7/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.7/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.7/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.7/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.7/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.7/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.7/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.7/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.7/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.7/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.7/lib/sidekiq/util.rb:24:in `block in safe_thread'


aws-sdk-core-3.96.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/request.rb:70:in `send_request'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:59:in `block in vacate_legacy_prefix'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `each'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `vacate_legacy_prefix'
/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.2.2/lib/rails_multisite/connection_management.rb:68:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.7/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.7/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.7/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.7/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.7/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.7/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.7/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.7/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.7/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.7/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.7/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.7/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.7/lib/sidekiq/util.rb:24:in `block in safe_thread'

Falco · 7. Juni 2020 um 15:46

Nutzt du echtes S3 oder einen Klon?

davidkingham · 7. Juni 2020 um 16:31

Ich nutze DigitalOcean Spaces, bin mir aber nicht sicher, ob das als ‘echt’ gilt?

Falco · 7. Juni 2020 um 18:40

Das sieht sehr ähnlich aus wie bei einem Klon, der einen API-Aufruf nicht unterstützt.

Sie sollten die Ordnerbereinigung manuell durchführen, damit Discourse nicht versucht, dies zu tun, da dies aufgrund der fehlenden APIs nicht möglich ist.

github.com/discourse/discourse

lib/backup_restore/s3_backup_store.rb

293467a37


      
          def vacate_legacy_prefix
            legacy_s3_helper = S3Helper.new(s3_bucket_name_with_legacy_prefix, '', @s3_options.clone)
            legacy_keys = legacy_s3_helper.list.map { |o| o.key }
            legacy_keys.each do |legacy_key|
              bucket, prefix = s3_bucket_name_with_prefix.split('/', 2)
              @s3_helper.s3_client.copy_object({
                copy_source: File.join(bucket, legacy_key),
                bucket: bucket,
                key: File.join(prefix, legacy_key.split('/').last)
              })
              legacy_s3_helper.delete_object(legacy_key)
            end
          end

davidkingham · 7. Juni 2020 um 19:01

Bitte entschuldigen Sie meine Unwissenheit, aber ich habe keine Ahnung, was das bedeutet. DO hat im vergangenen Jahr einwandfrei funktioniert, und dieses Problem ist erst seit dem Update auf die neueste Version vor einigen Tagen aufgetaucht.

davidkingham · 11. Juni 2020 um 16:55

Kann mir jemand das bitte klären? Der Job läuft schon seit 4 Tagen.

schleifer · 12. Juni 2020 um 03:10

Du triffst auf einen Fehler in diesem Job, sorry.

Die einfachste Lösung wäre:

Navigiere zu https://community.naturephotographers.network/admin/backups
Lösche dort die Einträge, die eine Größe von 5 GB oder mehr haben.

Alternativ kannst du sie manuell an den neuen Speicherort im Bucket verschieben, also wahrscheinlich nach backups/default/ statt wie bisher nach backups/.

Beim manuellen Verschieben tritt ein zweiter Fehler im Job auf, und die Logs melden den Fehler: This copy request is illegal because it is trying to copy an object to itself without changing the object's metadata, storage class, website redirect location or encryption attributes.

Ich habe einen Fix für diesen zweiten Fehler eingespielt. Wenn du also den manuellen Verschiebevorgang durchführst, wird der Fehler “illegal request” nach einem erneuten Update in Kürze nicht mehr auftreten.

davidkingham · 12. Juni 2020 um 03:29

Danke, Andrew, nur ein kleines Problem: mein größtes Backup ist 460 MB groß…

sam · 12. Juni 2020 um 04:35

Ich denke, das liegt daran, dass du eine S3-Kopie verwendest, sodass die API, die wir zum Verschieben von Daten nutzen, von DigitalOcean nicht implementiert wurde.

Kannst du die Daten manuell verschieben?

Am einfachsten wäre es, alle Backups herunterzuladen und dann alle alten Backups zu löschen.

davidkingham · 13. Juni 2020 um 17:29

Okay, ich habe alle Backups gelöscht, versucht, den Job zu stoppen, und er startet einfach neu. Muss ich noch etwas anderes tun, um ihn zurückzusetzen?

schleifer · 17. Juni 2020 um 10:51

Gibt es einen anderen Fehler in den Logs?

Ich würde versuchen, den Prozess neu zu starten, in der Hoffnung, dass er den Job-Status erneut bewertet.

cd /var/discourse
./launcher restart app

davidkingham · 17. Juni 2020 um 13:41

In den Logs gibt es keine Fehler mehr, der Job läuft jetzt einfach ständig in Sidekiq. Ich habe versucht, den Server neu zu starten und die App neu zu starten, aber das hat nichts gebracht.

schleifer · 17. Juni 2020 um 17:37

Versuchen Sie, dies auszuführen, und prüfen Sie, ob ein Fehler auftritt:

cd /var/discourse
./launcher enter app
rails console
BackupRestore::S3BackupStore.create.vacate_legacy_prefix

Wenn sich tatsächlich keine Sicherungen im Bucket befinden, sollte die letzte Zeile eine leere Liste ausgeben:

=> []

davidkingham · 18. Juni 2020 um 19:37

Danke, Andrew, ich habe es gerade wieder bereinigt und erhalte Folgendes:

[1] pry(main)> BackupRestore::S3BackupStore.create.vacate_legacy_prefix
=> []
[2] pry(main)>

Thema		Antworten	Aufrufe
Intended path to migrate S3 to local Self-hosting uploads , s3	5	850	13. Mai 2023
Sidekiq is being paused, how can I discover why? Support	18	3228	20. September 2018
Backups fail to upload to S3 several times- works eventually Support backups , s3	7	215	27. Mai 2025
Unable to backup or navigate to backups Bug s3	23	377	18. November 2024
Unknown items in Backup list Support	8	685	18. Januar 2019

Job VacateLegacyPrefixBackups hängt fest

Verwandte Themen