Probleme beim Update von 3.0.3 auf 3.0.4: Fehler 523

Hallo!

Ich stoße auf ein Problem, während ich versuche, meine Installation mit dem launcher-Dienstprogramm zu aktualisieren.

Ich erhalte einen Fehler 523, wenn der Build-Container versucht, den Besitz der hochgeladenen Bilder zu ändern…
Haben Sie eine Idee?

Hier ist das Protokoll:

$ 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 „Gefällt mir“

Ich kann nichts Nützliches über diesen Fehler finden. Was ist Ihre Betriebssystemdistribution und Version? Welche Art von Speicher wird für Uploads verwendet?

Ich hoffe, Sie wissen bereits, dass die Verwendung des ‘stable’-Tracks eine ungewöhnliche Taktik ist – fast jeder verwendet den ‘tests-passed’-Track. Siehe
Warum installiert Discourse immer „Beta“-Versionen standardmäßig?

Verwenden Sie S3 und ist der Name Ihres Buckets korrekt konfiguriert?

Aber es sollte nicht mehr fehlschlagen, also ist das meiner Meinung nach irrelevant?

Es könnte weniger fehlschlagen, wenn nur wenige Installationen Stable verwenden. Außerdem wollte ich sicherstellen, dass @gmoirod über die Situation informiert ist – ich vermute, dass einige Leute, die Stable verwenden, dies tun, ohne zu wissen, was es ist.

Ich verstehe das. Aber wenn seine Installation gerade fehlschlägt, dann schätze ich, dass ein Sprung auf 3.1.0beta5 es viel schlimmer machen wird. Konzentrieren wir uns also zuerst auf das Problem.

1 „Gefällt mir“

Ich betreibe Discourse als Docker-Container auf einem Debian 11 Server.
Meine Uploads befinden sich auf einem gemeinsam genutzten NFS-Mount. Das war schon immer so und ich hatte dieses Problem noch nie zuvor.

Ja, ich habe mehrere Dinge dazu gesehen… Ich muss es eines Tages tun…
Ich bin irgendwie ein Debian-Typ, wissen Sie. Behalten Sie “stable” für die Produktion bei.

Da haben Sie es. Und ist dieser Mount derzeit vom Container aus zugänglich?

Mein aktuell laufender Discourse 3.0.3 Container:

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

Innerhalb des Containers scheinen Besitzverhältnisse und Rechte gut zu sein

$ 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

Außerdem kann ich in laufendem Discourse 3.0.3 neue Bilder hochladen

Präzision: Ich habe SELinux/AppArmor nicht aktiviert

Ich hoffe, das hängt nicht zusammen :sob: #102728 - cvs: unknown error 523 - Debian Bug report logs

Tatsächlich ist dies kein Problem mit dem Repository auf NFS. Es ist ein Problem
mit dem NFS-gemounteten CLIENT-Verzeichnis.

Das Problem stellte sich als NFS-Bug im Linux-Kernel heraus, daher können Sie
diesen Bug wahrscheinlich schließen.

Dass etwas das Top-Ergebnis bei Google ist, bedeutet nicht, dass es das beste Ergebnis ist.

> Datum: Do, 28 Jun 2001 20:03:01 UTC

Können Sie chown aus dem Container heraus ausführen, d. h. den fehlerhaften Befehl manuell ausführen?

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

Ich fürchte, ich kann das (ich habe den Befehl korrigiert, da der ursprünglich ausgeführte Befehl falsch war) …

$ 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

Es hat lange gedauert, aber es gab keine Fehler.

Gibt es einen Unterschied im Docker-Image, das in 3.0.3 ausgeführt wird, und dem, das zum Erstellen des Images in 3.0.4 verwendet wird?

Docker-Image-Versionen sind nicht an Discourse-Versionen gebunden. Außerdem hängt es davon ab, wie Sie zuvor neu erstellt haben, daher ist es schwer zu sagen.

Mein aktuelles 3.0.3-Image gibt mir

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

Und das fehlerhafte verwendete:

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

Ich werde die Unterschiede überprüfen :mag:

Verdammt!
Ich kann nichts finden, was damit zusammenhängt: Comparing 3d317b7f58e8201912972afa3910b6c4b9ad8c75...main · discourse/discourse_docker · GitHub

Okay, es gibt definitiv ein Problem mit dem Basis-Image.
Ich habe erzwungen, dass discourse/base:2.0.20230409-0052 im Launcher verwendet wird, und es hat wie am Schnürchen funktioniert.

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

Kann irgendjemand die Ursache dieser Änderung sehen?

Ob Sie es glauben oder nicht, ich habe es gerade mit discourse/base:2.0.20230502-0058 neu erstellt und es hat funktioniert… :man_shrugging:

2 „Gefällt mir“

Kein Problem, Computerschabernack zu glauben :upside_down_face:

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