Tâche VacateLegacyPrefixBackups bloquée

davidkingham · Juin 7, 2020, 2:56

Cette tâche tourne depuis presque deux jours après la mise à jour. Cela semble-t-il normal ? Dois-je simplement l’arrêter dans Sidekiq ou existe-t-il une meilleure approche ? Merci !

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 · Juin 7, 2020, 3:46

Êtes-vous sur un vrai S3 ou utilisez-vous un clone ?

davidkingham · Juin 7, 2020, 4:31

J’utilise DigitalOcean Spaces, je ne suis pas sûr que cela soit considéré comme « réel » ?

Falco · Juin 7, 2020, 6:40

Cela ressemble beaucoup à ce qui se produit lorsqu’un clone ne prend pas en charge un appel d’API.

Vous devrez effectuer le nettoyage du dossier manuellement afin que votre Discourse n’essaie pas de le faire, car il ne le peut pas en raison des API manquantes.

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 · Juin 7, 2020, 7:01

Veuillez m’excuser pour mon ignorance, mais je ne sais absolument pas ce que cela signifie. DO a bien fonctionné au cours de la dernière année, et ce problème n’est apparu qu’après la mise à jour vers la version la plus récente l’autre jour.

davidkingham · Juin 11, 2020, 4:55

Quelqu’un peut-il éclaircir cela ? Le travail est toujours en cours 4 jours plus tard.

schleifer · Juin 12, 2020, 3:10

Vous rencontrez un bug dans cette tâche, désolé.

La solution la plus simple serait :

Rendez-vous sur https://community.naturephotographers.network/admin/backups
Supprimez les entrées dont la taille est de 5 Go ou plus dans la colonne « Size »

Sinon, vous pouvez les déplacer manuellement vers l’emplacement du bucket, qui serait probablement backups/default/ au lieu de l’emplacement actuel backups/.

Le déplacement manuel se heurtera à un deuxième bug dans la tâche, et les journaux afficheront l’erreur : Cette requête de copie est illégale car elle tente de copier un objet sur lui-même sans modifier ses métadonnées, sa classe de stockage, son emplacement de redirection de site ou ses attributs de chiffrement.

J’ai apporté une correction à ce deuxième bug. Ainsi, si vous effectuez le déplacement manuel, une mise à jour ultérieure dans quelques instants fera disparaître le message d’erreur « requête illégale ».

davidkingham · Juin 12, 2020, 3:29

Merci Andrew, juste un petit problème, ma plus grande sauvegarde fait 460 Mo…

sam · Juin 12, 2020, 4:35

Je pense que cela est dû au fait que vous êtes sur un clone S3, donc l’API que nous utilisons pour déplacer des éléments n’est pas implémentée par DigitalOcean.

Pouvez-vous déplacer les éléments manuellement ?

La chose la plus simple à faire serait de télécharger toutes les sauvegardes, puis de supprimer toutes les anciennes sauvegardes.

davidkingham · Juin 13, 2020, 5:29

D’accord, j’ai supprimé tous les backups, j’ai essayé d’arrêter le travail et il redémarre simplement. Y a-t-il autre chose que je dois faire pour le réinitialiser ?

schleifer · Juin 17, 2020, 10:51

Y a-t-il une autre erreur dans les journaux ?

Je tenterais de redémarrer le processus pour espérer qu’il réévalue l’état du travail.

cd /var/discourse
./launcher restart app

davidkingham · Juin 17, 2020, 1:41

Il n’y a plus d’erreurs dans les journaux, le problème est que le travail s’exécute en continu dans Sidekiq. J’ai essayé de redémarrer le serveur et de relancer l’application, mais sans succès.

schleifer · Juin 17, 2020, 5:37

Essayez d’exécuter ceci et voyez si cela génère une erreur :

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

S’il n’y a vraiment aucun sauvegarde dans le bac, la dernière ligne devrait afficher une liste vide :

=> []

davidkingham · Juin 18, 2020, 7:37

Merci Andrew, je l’ai à nouveau vidé et j’obtiens ceci :

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

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

Tâche VacateLegacyPrefixBackups bloquée

Sujets connexes