Problemas al actualizar de 3.0.3 a 3.0.4: Error 523

Hola!

Me encuentro con un problema al intentar actualizar mi instalación con la utilidad launcher.

Obtengo un error 523 cuando el contenedor de compilación intenta cambiar la propiedad de las imágenes cargadas…
¿Alguna idea?

Aquí está el log:

$ sudo ./launcher rebuild app
Se detectó la arquitectura x86_64.
ADVERTENCIA: el archivo containers/app.yml es legible por todos. Puedes proteger este archivo ejecutando: chmod o-rwx containers/app.yml
Asegurando que launcher esté actualizado
Obteniendo origen
Launcher está actualizado
Deteniendo el contenedor antiguo
+ /usr/bin/docker stop -t 600 app
app
2.0.20230502-0058: Extrayendo de discourse/base
Digest: sha256:fa95da36c3d3a582d644b139ec678f5778d745697454bc86f598c689031b30aa
Estado: La imagen está actualizada para discourse/base:2.0.20230502-0058
docker.io/discourse/base:2.0.20230502-0058
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups.rb
/usr/local/bin/pups --stdin

.....

Cambiado a una nueva rama 'stable'
I, [2023-06-18T16:43:24.458070 #1]  INFO -- : Rama 'stable' configurada para rastrear la rama remota 'stable' desde 'origin'.

I, [2023-06-18T16:43:24.458386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.469320 #1]  INFO -- : 
I, [2023-06-18T16:43:24.469386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.472481 #1]  INFO -- : 
I, [2023-06-18T16:43:24.472660 #1]  INFO -- : 
I, [2023-06-18T16:43:24.476232 #1]  INFO -- : 
I, [2023-06-18T16:43:24.476303 #1]  INFO -- : 
I, [2023-06-18T16:43:24.479386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.479449 #1]  INFO -- : 
I, [2023-06-18T16:43:24.482943 #1]  INFO -- : 
I, [2023-06-18T16:43:24.483012 #1]  INFO -- : 
I, [2023-06-18T16:43:24.486152 #1]  INFO -- : 
I, [2023-06-18T16:43:24.486220 #1]  INFO -- : 
I, [2023-06-18T16:43:24.489788 #1]  INFO -- : 
I, [2023-06-18T16:43:24.489954 #1]  INFO -- : 
I, [2023-06-18T16:43:24.495214 #1]  INFO -- : 
I, [2023-06-18T16:43:24.495285 #1]  INFO -- : 
I, [2023-06-18T16:43:24.500211 #1]  INFO -- : 
I, [2023-06-18T16:43:24.500283 #1]  INFO -- : 
I, [2023-06-18T16:43:24.504652 #1]  INFO -- : 
I, [2023-06-18T16:43:24.504738 #1]  INFO -- : 
I, [2023-06-18T16:43:24.512836 #1]  INFO -- : 
I, [2023-06-18T16:43:24.512942 #1]  INFO -- : 
I, [2023-06-18T16:43:24.518383 #1]  INFO -- : 
I, [2023-06-18T16:43:24.518453 #1]  INFO -- : 
I, [2023-06-18T16:43:24.523090 #1]  INFO -- : 
I, [2023-06-18T16:43:24.523195 #1]  INFO -- : 
chown: /shared/uploads/default/optimized/1X: Error desconocido 523
chown: /shared/uploads/default/original/1X: Error desconocido 523
I, [2023-06-18T16:43:41.385629 #1]  INFO -- : 


FALLÓ
--------------------
Pups::ExecError: cd /var/www/discourse && chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp falló con el retorno #<Process::Status: pid 135 exit 1>
Ubicación del fallo: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falló con los parámetros {"cd"=>"$home", "hook"=>"code", "cmd"=>["sudo -H -E -u discourse git reset --hard", "sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [ $(git rev-parse --is-shallow-repository) == \"true\" ]; then\n      git remote set-branches --add origin main\n      git remote set-branches origin $version\n      git fetch --depth 1 origin $version\n  else\n      git fetch --tags --prune-tags --prune --force origin\n  fi\n'", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\n      git pull\n  else\n      git -c advice.detachedHead=false checkout $version\n  fi\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap falló con el código de salida 1
** FALLÓ EL BOOTSTRAP ** por favor desplázate hacia arriba y busca mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
2 Me gusta

No encuentro nada útil sobre este error. ¿Cuál es tu distribución y versión del sistema operativo? ¿Qué tipo de almacenamiento se utiliza para las cargas?

Espero que ya sepas que usar la vía ‘estable’ es una táctica inusual; casi todo el mundo utiliza la vía ‘tests-passed’. Consulta
¿Por qué Discourse siempre instala las versiones “beta” por defecto?

¿Estás usando S3 y, en caso afirmativo, está configurado correctamente el nombre de tu bucket?

Pero no debería fallar más, ¿así que esto es irrelevante en mi opinión?

Podría verse que falla menos, si muy pocas instalaciones usan estable. Además, quería asegurarme de que @gmoirod estuviera al tanto de la situación; supongo que algunas personas que ejecutan estable lo hacen sin saber lo que es.

Entiendo. Pero si su instalación está fallando ahora mismo, estimo que pasar a la versión 3.1.0beta5 lo empeorará mucho. Así que centrémonos primero en el problema.

1 me gusta

Ejecuto Discourse como contenedores docker sobre un servidor Debian 11.
Mis cargas están en un montaje NFS compartido. Este siempre ha sido el caso y nunca antes había tenido este problema.

Sí, vi varias cosas sobre esto… Tengo que hacerlo algún día…
Soy un poco de la onda Debian, ya sabes. Mantén “estable” para producción.

Ahí lo tienes. ¿Y ese montaje es accesible actualmente desde dentro del contenedor?

Mi contenedor de Discourse 3.0.3 en ejecución real:

            {
                "Type": "bind",
                "Source": "/nfsdata/discourse-data-shared/uploads",
                "Destination": "/shared/uploads",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },

Dentro del contenedor, las posesiones y los derechos parecen correctos

$ sudo docker exec app sh -c "ls -al /shared/uploads /shared/uploads/default/optimized/1X /shared/uploads/default/original/1X"
/shared/uploads:
total 4
drwxr-xr-x  2 discourse www-data    0 Jun 20 20:07 .
drwxr-xr-x 10 root      root     4096 Mar  8 16:29 ..
drwxr-xr-x  2 discourse www-data    0 Jun  8  2022 default
drwxr-xr-x  2 discourse www-data    0 Mar  8 17:34 tombstone

/shared/uploads/default/optimized/1X:
total 17094
drwxr-xr-x 2 discourse www-data      0 Mar 22 11:30 .
drwxr-xr-x 2 discourse www-data      0 Mar  8 16:18 ..
-rw-r--r-- 1 discourse www-data  54700 Mar  8 16:52 00964701d199ec0d6d3dd5269c842e1f0bb7e7a1_2_1035x456.png
-rw-r--r-- 1 discourse www-data    205 Mar  8 16:52 00964701d199ec0d6d3dd5269c842e1f0bb7e7a1_2_10x10.png
.....

/shared/uploads/default/original/1X:
total 17932
drwxr-xr-x 2 discourse www-data       0 Apr 23 11:42 .
drwxr-xr-x 2 discourse www-data       0 Jun  8  2022 ..
-rw-r--r-- 1 discourse www-data   35706 Nov 18  2022 00964701d199ec0d6d3dd5269c842e1f0bb7e7a1.png
-rwxr-xr-x 1 discourse www-data   17112 Jul  4  2022 00a82b03ffbcdf56e34f86adbec263e12573f49b.png

Además, puedo subir nuevas imágenes en Discourse 3.0.3 en ejecución.

Precisión: No tengo SELinux/AppArmor activado

Esperando que esto no esté relacionado :sob: #102728 - cvs: unknown error 523 - Debian Bug report logs

En realidad, esto no es un problema con el repositorio en NFS. Es un problema
con el directorio CLIENT montado en NFS.

El problema resultó ser un error de NFS en el kernel de Linux, por lo que probablemente
pueda cerrar este error.

Que algo sea el primer resultado en Google no significa que sea el mejor resultado.

Fecha: Jue, 28 Jun 2001 20:03:01 UTC

¿Puedes ejecutar chown desde dentro del contenedor, es decir, ejecutar el comando fallido manualmente?

sudo docker exec app sh -c "chown -R discourse:discourse /shared/uploads/default/optimized/1X"

Me temo que sí puedo (corregí el comando ya que el ejecutado inicialmente era incorrecto)…

$ docker exec -it app bash
app:/$ cd /var/www/discourse
app:/var/www/discourse$ chown -R discourse:www-data /shared/uploads
app:/var/www/discourse$ echo $?
0

Tardó mucho pero no hubo error.

¿Hay alguna diferencia en la imagen de docker que se ejecuta en la 3.0.3 y la que se usó para construir la imagen en la 3.0.4?

Las versiones de las imágenes de Docker no están vinculadas a las versiones de Discourse. Además, depende de cómo reconstruiste antes, por lo que es difícil decirlo.

Mi imagen real 3.0.3 me da

# docker image inspect local_discourse/app | grep 'discourse/base'
            "Image": "discourse/base:2.0.20230409-0052",

Y la que está en error usó:

Status: Image is up to date for discourse/base:2.0.20230502-0058

Voy a comprobar la diferencia :mag:

¡Maldición!
No veo nada relacionado: Comparing 3d317b7f58e8201912972afa3910b6c4b9ad8c75...main · discourse/discourse_docker · GitHub

De acuerdo, definitivamente hay un problema con la imagen base.
Forcé el uso de discourse/base:2.0.20230409-0052 en el lanzador y funcionó a la perfección.

# git diff launcher
diff --git a/launcher b/launcher
index 3e1a1c4..8a989b8 100755
--- a/launcher
+++ b/launcher
@@ -92,7 +92,7 @@ kernel_min_version='4.4.0'
 config_file=containers/"$config".yml
 cidbootstrap=cids/"$config"_bootstrap.cid
 local_discourse=local_discourse
-image="discourse/base:2.0.20230502-0058"
+image="discourse/base:2.0.20230409-0052"
 docker_path=`which docker.io 2> /dev/null || which docker`
 git_path=`which git`

¿Alguien puede ver el cambio que causa esto?

Lo creas o no, acabo de reconstruir de nuevo con discourse/base:2.0.20230502-0058 y pasó… :man_shrugging:

2 Me gusta

No tengo problemas en creer en las travesuras informáticas :upside_down_face:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.