Проблемы при обновлении с 3.0.3 до 3.0.4: ошибка 523

Привет!

У меня возникла проблема при попытке обновить установку с помощью утилиты launcher.

Получаю ошибку 523, когда контейнер сборки пытается изменить владельца загруженных изображений…
Есть какие-то идеи?

Вот лог:

$ 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 -- : > cd /var/www/discourse && sudo -H -E -u discourse git config user.discourse-version stable
I, [2023-06-18T16:43:24.469320 #1]  INFO -- : 
I, [2023-06-18T16:43:24.469386 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp
I, [2023-06-18T16:43:24.472481 #1]  INFO -- : 
I, [2023-06-18T16:43:24.472660 #1]  INFO -- : > cd /var/www/discourse && chown discourse:www-data tmp
I, [2023-06-18T16:43:24.476232 #1]  INFO -- : 
I, [2023-06-18T16:43:24.476303 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp/pids
I, [2023-06-18T16:43:24.479386 #1]  INFO -- : 
I, [2023-06-18T16:43:24.479449 #1]  INFO -- : > cd /var/www/discourse && mkdir -p tmp/sockets
I, [2023-06-18T16:43:24.482943 #1]  INFO -- : 
I, [2023-06-18T16:43:24.483012 #1]  INFO -- : > cd /var/www/discourse && touch tmp/.gitkeep
I, [2023-06-18T16:43:24.486152 #1]  INFO -- : 
I, [2023-06-18T16:43:24.486220 #1]  INFO -- : > cd /var/www/discourse && mkdir -p                    /shared/log/rails
I, [2023-06-18T16:43:24.489788 #1]  INFO -- : 
I, [2023-06-18T16:43:24.489954 #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.495214 #1]  INFO -- : 
I, [2023-06-18T16:43:24.495285 #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.500211 #1]  INFO -- : 
I, [2023-06-18T16:43:24.500283 #1]  INFO -- : > cd /var/www/discourse && bash -c "mkdir -p           /shared/{uploads,backups}"
I, [2023-06-18T16:43:24.504652 #1]  INFO -- : 
I, [2023-06-18T16:43:24.504738 #1]  INFO -- : > cd /var/www/discourse && bash -c "ln    -s           /shared/{uploads,backups} /var/www/discourse/public"
I, [2023-06-18T16:43:24.512836 #1]  INFO -- : 
I, [2023-06-18T16:43:24.512942 #1]  INFO -- : > cd /var/www/discourse && bash -c "mkdir -p           /shared/tmp/{backups,restores}"
I, [2023-06-18T16:43:24.518383 #1]  INFO -- : 
I, [2023-06-18T16:43:24.518453 #1]  INFO -- : > cd /var/www/discourse && bash -c "ln    -s           /shared/tmp/{backups,restores} /var/www/discourse/tmp"
I, [2023-06-18T16:43:24.523090 #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.

Я не могу найти ничего полезного об этой ошибке. Какая у вас дистрибуция и версия ОС? Какой тип хранилища используется для загрузки файлов?

Надеюсь, вы уже знаете, что использование трека ‘stable’ — это необычная тактика; почти все используют трек ‘tests-passed’. См.
Почему Discourse по умолчанию всегда устанавливает «бета-версии»?

Используете ли вы S3 и если да, то правильно ли настроено имя вашего бакета?

Но это не должно приводить к ещё большим сбоям, так что это не имеет значения, на мой взгляд?

Это может казаться менее проблемным, если очень мало установок используют стабильную версию. Также я хотел убедиться, что @gmoirod в курсе ситуации — предполагаю, что некоторые люди, использующие стабильную версию, делают это, не понимая, что это такое.

Понимаю. Но если его установка сейчас не проходит, то, по моему мнению, переход на версию 3.1.0beta5 только усугубит ситуацию. Поэтому давайте сначала сосредоточимся на проблеме.

Я запускаю Discourse в контейнерах Docker на сервере под управлением Debian 11.
Мои загрузки размещены на общем NFS-монтировании. Это всегда было так, и раньше у меня никогда не возникало этой проблемы.

Да, я видел несколько вещей на эту тему… Когда-нибудь мне придется перейти на него…
Вы же знаете, я человек из мира Debian. Оставляю “stable” для продакшена.

Вот и всё. И доступен ли этот том в данный момент из контейнера?

Мой запущенный контейнер Discourse 3.0.3:

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

Внутри контейнера права доступа и владельцы кажутся правильными.

$ 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

Кроме того, я могу загружать новые изображения в запущенный Discourse 3.0.3.

Точность: У меня не активированы SELinux/AppArmor

Надеюсь, это не связано :sob: I Challenge Thee

На самом деле, проблема не в репозитории на NFS. Это проблема
с каталогом клиента, смонтированным через NFS.

Оказалось, что проблема вызвана ошибкой NFS в ядре Linux, поэтому вы, вероятно,
можете закрыть этот баг.

То, что что-то является первым результатом в Google, не означает, что это лучший результат.

Дата: чт, 28 июн 2001 20:03:01 UTC

Можете ли вы выполнить chown изнутри контейнера, то есть запустить команду, вызывающую сбой, вручную?

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

Боюсь, что могу (я исправил команду, так как изначально была выполнена другая) …

$ 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

Заняло много времени, но ошибок не возникло.

Есть ли какие-либо различия между образом Docker, работающим в версии 3.0.3, и тем, который использовался для сборки образа в версии 3.0.4?

Версии образов Docker не привязаны к версиям Discourse. Кроме того, это зависит от того, как вы выполняли пересборку ранее, поэтому трудно сказать точно.

Мой реальный образ 3.0.3 выдает:

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

А тот, что вызвал ошибку, использовал:

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

Я проверю различия :mag:

Чёрт! :frowning:
Ничего связанного не вижу: Comparing 3d317b7f58e8201912972afa3910b6c4b9ad8c75...main · discourse/discourse_docker · GitHub

Да, проблема точно в базовом образе.
Я принудительно указал использование discourse/base:2.0.20230409-0052 в launcher, и всё заработало как по маслу.

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

Может кто-то увидеть, какое именно изменение вызывает эту проблему?

Верите или нет, я только что снова пересобрал образ с использованием discourse/base:2.0.20230502-0058, и всё прошло успешно… :man_shrugging:

Нетрудно поверить в компьютерные проделки :upside_down_face: