Tarea VacateLegacyPrefixBackups detenida

davidkingham · 7 Junio, 2020 14:56

Este trabajo ha estado ejecutándose durante casi dos días después de la actualización. ¿Esto parece normal? ¿Debo detenerlo directamente en Sidekiq o hay una mejor manera de abordarlo? ¡Gracias!

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 Junio, 2020 15:46

¿Estás en S3 real o usando un clon?

davidkingham · 7 Junio, 2020 16:31

Estoy usando DigitalOcean Spaces, no estoy seguro de si eso se considera ‘real’.

Falco · 7 Junio, 2020 18:40

Eso parece muy similar a lo que ocurre cuando un clon no admite una llamada a la API.

Deberás realizar la limpieza de carpetas manualmente para que tu Discourse no intente hacerlo, ya que no puede debido a las APIs faltantes.

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 Junio, 2020 19:01

Por favor, disculpa mi ignorancia, pero no tengo ni idea de qué significa eso. DO ha funcionado bien durante el último año y esto solo apareció después de actualizar a la última versión el otro día.

davidkingham · 11 Junio, 2020 16:55

¿Puede alguien aclarar esto? El trabajo sigue ejecutándose después de 4 días.

schleifer · 12 Junio, 2020 03:10

Estás tropezando con un error en esa tarea, lo siento.

La solución más sencilla sería:

Navega a https://community.naturephotographers.network/admin/backups
Elimina las entradas allí que tengan 5 GB o más en la columna ‘Size’.

Alternativamente, puedes moverlas manualmente a la nueva ubicación en el bucket, que probablemente sea backups/default/ en lugar de la actual backups/.

Moverlas manualmente encontrará un segundo error en la tarea, y los registros mostrarán el error: Esta solicitud de copia es ilegal porque está intentando copiar un objeto a sí mismo sin cambiar los metadatos del objeto, la clase de almacenamiento, la ubicación de redirección del sitio web o los atributos de cifrado.

He aplicado una corrección para ese segundo error, por lo que si realizas el movimiento manual, actualizar de nuevo en un momento detendrá el mensaje de error de “solicitud ilegal”.

davidkingham · 12 Junio, 2020 03:29

Gracias, Andrew, solo un pequeño problema, mi copia de seguridad más grande es de 460 MB…

sam · 12 Junio, 2020 04:35

Creo que esto está ocurriendo porque estás en una réplica de S3, por lo que la API que utilizamos para mover archivos no está implementada por DigitalOcean.

¿Puedes mover los archivos manualmente?

Lo más sencillo sería descargar todas las copias de seguridad y luego eliminar todas las antiguas.

davidkingham · 13 Junio, 2020 17:29

Bien, eliminé todas las copias de seguridad, intenté detener el trabajo y simplemente se reinicia. ¿Hay algo más que deba hacer para restablecerlo?

schleifer · 17 Junio, 2020 10:51

¿Hay algún otro error en los registros?

Te sugiero reiniciar el proceso para que, con suerte, vuelva a evaluar el estado del trabajo.

cd /var/discourse
./launcher restart app

davidkingham · 17 Junio, 2020 13:41

Ya no hay errores en los registros; el problema es que el trabajo se está ejecutando continuamente en Sidekiq. Intenté reiniciar el servidor y volver a iniciar la aplicación, pero sin éxito.

schleifer · 17 Junio, 2020 17:37

Intenta ejecutar esto y verifica si genera un error:

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

Si realmente no hay copias de seguridad en el bucket, la última línea debería mostrar una lista vacía:

=> []

davidkingham · 18 Junio, 2020 19:37

Gracias, Andrew. Acabo de limpiarlo de nuevo y obtengo esto:

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

Tema		Respuestas	Vistas
Intended path to migrate S3 to local Self-hosting uploads , s3	5	850	13 Mayo 2023
Sidekiq is being paused, how can I discover why? Support	18	3228	20 Septiembre 2018
Backups fail to upload to S3 several times- works eventually Support backups , s3	7	215	27 Mayo 2025
Unable to backup or navigate to backups Bug s3	23	377	18 Noviembre 2024
Unknown items in Backup list Support	8	685	18 Enero 2019

Tarea VacateLegacyPrefixBackups detenida

Temas relacionados