Problèmes lors de la mise à jour de 3.0.3 à 3.0.4 : Erreur 523

Salut !

J’ai rencontré un problème en essayant de mettre à niveau mon installation avec l’utilitaire launcher.

J’obtiens une erreur 523 lorsque le conteneur de build essaie de changer la propriété des images téléchargées…
Des idées ?

Voici le log :

$ sudo ./launcher rebuild app
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 600 app
app
2.0.20230502-0058: Pulling from discourse/base
Digest: sha256:fa95da36c3d3a582d644b139ec678f5778d745697454bc86f598c689031b30aa
Status: Image is up to date for 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

.....

Switched to a new branch 'stable'
I, [2023-06-18T16:43:24.458070 #1]  INFO -- : Branch 'stable' set up to track remote branch 'stable' from 'origin'.

I, [2023-06-18T16:43:24.458386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.469320 #1]  INFO -- : > cd /var/www/discourse && sudo -H -E -u discourse git config user.discourse-version stable
I, [2023-06-18T16:43:24.469386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.472481 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp
I, [2023-06-18T16:43:24.472660 #1]  INFO -- : 
I, [2023-06-18T16:43:24.476232 #1]  INFO -- : > cd /var/www/discourse && chown discourse:www-data tmp
I, [2023-06-18T16:43:24.476303 #1]  INFO -- : 
I, [2023-06-18T16:43:24.479386 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp/pids
I, [2023-06-18T16:43:24.479449 #1]  INFO -- : 
I, [2023-06-18T16:43:24.482943 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp/sockets
I, [2023-06-18T16:43:24.483012 #1]  INFO -- : 
I, [2023-06-18T16:43:24.486152 #1]  INFO -- : > cd /var/www/discourse && touch tmp/.gitkeep
I, [2023-06-18T16:43:24.486220 #1]  INFO -- : 
I, [2023-06-18T16:43:24.489788 #1]  INFO -- : > cd /var/www/discourse && mkdir -p                    /shared/log/rails
I, [2023-06-18T16:43:24.489954 #1]  INFO -- : 
I, [2023-06-18T16:43:24.495214 #1]  INFO -- : > cd /var/www/discourse && bash -c "touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log"
I, [2023-06-18T16:43:24.495285 #1]  INFO -- : 
I, [2023-06-18T16:43:24.500211 #1]  INFO -- : > cd /var/www/discourse && bash -c "ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log /var/www/discourse/log"
I, [2023-06-18T16:43:24.500283 #1]  INFO -- : 
I, [2023-06-18T16:43:24.504652 #1]  INFO -- : > cd /var/www/discourse && bash -c "mkdir -p           /shared/{uploads,backups}"
I, [2023-06-18T16:43:24.504738 #1]  INFO -- : 
I, [2023-06-18T16:43:24.512836 #1]  INFO -- : > cd /var/www/discourse && bash -c "ln    -s           /shared/{uploads,backups} /var/www/discourse/public"
I, [2023-06-18T16:43:24.512942 #1]  INFO -- : 
I, [2023-06-18T16:43:24.518383 #1]  INFO -- : > cd /var/www/discourse && bash -c "mkdir -p           /shared/tmp/{backups,restores}"
I, [2023-06-18T16:43:24.518453 #1]  INFO -- : 
I, [2023-06-18T16:43:24.523090 #1]  INFO -- : > cd /var/www/discourse && bash -c "ln    -s           /shared/tmp/{backups,restores} /var/www/discourse/tmp"
I, [2023-06-18T16:43:24.523195 #1]  INFO -- : 
I, [2023-06-18T16:43:24.523195 #1]  INFO -- : > cd /var/www/discourse && chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp
chown: /shared/uploads/default/optimized/1X: Unknown error 523
chown: /shared/uploads/default/original/1X: Unknown error 523
I, [2023-06-18T16:43:41.385629 #1]  INFO -- : 

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp failed with return #<Process::Status: pid 135 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"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 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.
2 « J'aime »

Je n’ai rien trouvé d’utile à propos de cette erreur. Quelle est votre distribution et version d’OS ? Quel type de stockage est utilisé pour les téléversements ?

J’espère que vous savez déjà qu’utiliser la branche « stable » est une tactique inhabituelle - presque tout le monde utilise la branche « tests-passed ». Voir
Pourquoi Discourse installe-t-il toujours les versions « bêta » par défaut ?

Utilisez-vous S3 et, si oui, le nom de votre bucket est-il correctement configuré ?

Mais cela ne devrait pas échouer plus, donc c’est sans importance selon moi ?

Cela pourrait être considéré comme un échec moindre si très peu d’installations utilisent la version stable. De plus, je voulais m’assurer que @gmoirod était au courant de la situation - je suppose que certaines personnes qui utilisent la version stable l’exécutent sans savoir ce que c’est.

Je comprends. Mais si son installation échoue en ce moment, j’estime que passer à la version 3.1.0beta5 ne fera qu’empirer les choses. Concentrons-nous donc d’abord sur le problème.

1 « J'aime »

J’exécute Discourse en tant que conteneurs Docker sur un serveur Debian 11.
Mes téléchargements se trouvent sur un montage NFS partagé. Cela a toujours été le cas et je n’ai jamais eu ce problème auparavant.

Oui, j’ai vu plusieurs choses à ce sujet… Je devrai m’y mettre un jour…
Je suis un peu un gars de Debian, vous savez. Gardez « stable » pour la production.

Voilà. Et ce montage est-il actuellement accessible depuis l’intérieur du conteneur ?

Mon conteneur Discourse 3.0.3 actuellement en cours d’exécution :

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

Dans le conteneur, les propriétaires et les droits semblent corrects

$ 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

De plus, je suis capable de télécharger de nouvelles images dans Discourse 3.0.3 en cours d’exécution.

Précision : Je n’ai pas SELinux/AppArmor activé

J’espère que ce n’est pas lié :sob: #102728 - cvs: unknown error 523 - Debian Bug report logs

En fait, ce n’est pas un problème avec le dépôt sur NFS. C’est un problème
avec le répertoire CLIENT monté sur NFS.

Le problème s’est avéré être un bug NFS dans le noyau Linux, vous pouvez donc
probablement fermer ce bug.

Le fait que quelque chose soit le premier résultat sur Google ne signifie pas que c’est le meilleur résultat.

> Date : jeu. 28 juin 2001 20:03:01 UTC

Êtes-vous capable de chown depuis l’intérieur du conteneur, c’est-à-dire d’exécuter la commande défaillante manuellement ?

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

Je crains que oui (j’ai corrigé la commande par rapport à celle exécutée initialement)…

$ 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

Cela a pris du temps mais aucune erreur.

Y a-t-il une différence dans l’image docker exécutée dans la version 3.0.3 et celle utilisée pour construire l’image dans la version 3.0.4 ?

Les versions des images Docker ne sont pas liées aux versions de Discourse. De plus, cela dépend de la façon dont vous avez reconstruit auparavant, il est donc difficile de le dire.

Mon image 3.0.3 actuelle me donne

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

Et celle en erreur utilisait :

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

Je vais vérifier la différence :mag:

Zut !
Je ne vois rien qui s’y rapporte : Comparing 3d317b7f58e8201912972afa3910b6c4b9ad8c75...main · discourse/discourse_docker · GitHub

Il y a définitivement un problème avec l’image de base.
J’ai forcé l’utilisation de discourse/base:2.0.20230409-0052 dans le lanceur et cela a fonctionné à merveille.

# 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`

Quelqu’un peut-il voir le changement qui cause cela ?

Croyez-le ou non, je viens de reconstruire à nouveau avec discourse/base:2.0.20230502-0058 et ça a fonctionné… :man_shrugging:

2 « J'aime »

Pas de mal à croire aux farces informatiques :upside_down_face:

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