Проблема с обновлением Discourse

Поддержка Самостоятельное хостинг
1

Здравствуйте,

Я обновляю Discourse с версии v2.3.0.beta8 +212 до 2.4.0.beta1.

Сначала я обновил Docker-менеджер через веб-интерфейс. Затем веб-интерфейс сообщил, что необходимо выполнить обновление через командную строку, и я это сделал.

При обновлении у меня повторяются ошибки. Я запускаю:

cd /var/discourse
./launcher rebuild app

Процесс выполняется несколько минут, затем завершается с ошибкой при обновлении базы данных. Я перезагрузил сервер, что позволило снова запустить Discourse (но без обновления), и попытался снова. Ошибка та же.

Есть ли какие-либо предложения по дальнейшим действиям?

Вот последние строки вывода при запуске rebuild:

Optimizing site icons...
I, [2019-07-09T01:22:18.589503 #13]  INFO -- : Terminating async processes
I, [2019-07-09T01:22:18.589624 #13]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 67
I, [2019-07-09T01:22:18.589816 #13]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2019-07-09 01:22:18.589 UTC [67] LOG:  received fast shutdown request
183:signal-handler (1562635338) Received SIGTERM scheduling shutdown...
2019-07-09 01:22:18.593 UTC [67] LOG:  aborting any active transactions
2019-07-09 01:22:18.599 UTC [67] LOG:  worker process: logical replication launcher (PID 76) exited with exit code 1
2019-07-09 01:22:18.599 UTC [71] LOG:  shutting down
2019-07-09 01:22:18.629 UTC [67] LOG:  database system is shut down
183:M 09 Jul 2019 01:22:18.645 # User requested shutdown...
183:M 09 Jul 2019 01:22:18.645 * Saving the final RDB snapshot before exiting.
183:M 09 Jul 2019 01:22:18.672 * DB saved on disk
183:M 09 Jul 2019 01:22:18.672 # Redis is now ready to exit, bye bye...


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 366 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
cbaaf74d12f5c22faf7f054d391f3570b5e7d8dd3b8bce421c57ef17c4b43c55
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

Редактирование: Единственные ошибки в полном логе — это:

I, [2019-07-09T01:21:35.162142 #13]  INFO -- : > su postgres -c 'createdb discourse' || true
2019-07-09 01:21:35.330 UTC [80] postgres@postgres ERROR:  database "discourse" already exists
2019-07-09 01:21:35.330 UTC [80] postgres@postgres STATEMENT:  CREATE DATABASE discourse;
createdb: database creation failed: ERROR:  database "discourse" already exists
I, [2019-07-09T01:21:35.332706 #13]  INFO -- :
I, [2019-07-09T01:21:35.333101 #13]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
2019-07-09 01:21:35.444 UTC [91] postgres@discourse ERROR:  role "discourse" already exists
2019-07-09 01:21:35.444 UTC [91] postgres@discourse STATEMENT:  create user discourse;
ERROR:  role "discourse" already exists

Я заметил, что процесс завершается после строки “Optimizing Site Icons…” — возможно, здесь проблема?

2

Попробуйте поискать «error role discourse already exists»

3

Поиск по этому термину не дал полезных результатов:

  • в некоторых сообщениях упоминались плагины, я отключил их в app.yml
  • появилось сообщение о устаревшей версии Docker, я обновил её
  • запустил discourse doctor

Те же ошибки.

Во вложении вывод команды launch rebuild.

Есть ли какие-то предложения, что делать дальше?

скрипт rebuild.txt (140,9 КБ)

4

Стоит отметить, что в моем файле app.xml указан корень относительного URL. Не могло ли это помешать обновлению?

env:
  DISCOURSE_RELATIVE_URL_ROOT: /epicenter/support

run:
  - exec: echo "Начало пользовательских команд"

  - exec:
        cd: $home
        cmd:
          - mkdir -p public/epicenter/support
          - cd public/epicenter/support && ln -s ../../uploads && ln -s ../../backups
          - rm public/uploads
          - rm public/backups
  - replace:
       global: true
       filename: /etc/nginx/conf.d/discourse.conf
       from: proxy_pass http://discourse;
       to: |
          rewrite ^/(.*)$ /epicenter/support/$1 break;
          proxy_pass http://discourse;
  - replace:
       filename: /etc/nginx/conf.d/discourse.conf
       from: etag off;
       to: |
          etag off;
          location /epicenter/support {
             rewrite ^/epicenter/support/?(.*)$ /$1;
          }
  - replace:
         filename: /etc/nginx/conf.d/discourse.conf
         from: $proxy_add_x_forwarded_for
         to: $http_fastly_client_ip
         global: true
5

Наконец-то мне удалось заставить это работать на третьей или четвёртой рабочей сессии. Проблема, похоже, заключалась в отсутствующих изображениях в папке «uploads». Решение состояло в том, чтобы создать новую установку, использовать тот же файл «app.yml» и восстановить из резервной копии, добавив фиктивные файлы для отсутствующих изображений.

Параллельно с основной проблемой я заметил, что после предыдущего обновления различные значки и изображения исчезли. Когда я попытался пересобрать систему, в логах было указано, что процесс завершается после «оптимизации изображений сайта». Мне кажется, он застрял на каком-то пропущенном изображении и завершился без записи конкретной ошибки. (Не было никаких указаний на то, что проблема в отсутствующих изображениях, или на то, какие именно файлы изображений отсутствовали).

В итоге я создал новую установку Discourse с последней версией. Я восстановился из резервной копии следуя инструкциям здесь. Это заняло у меня три попытки.

Сначала скрипт резервного копирования выдал ошибку, так как не нашёл загруженные файлы, поэтому я скопировал папку uploads/default из своих предыдущих резервных копий.

Затем я снова запустил скрипт восстановления. На этот раз появилась ошибка о том, что не найден конкретный файл изображения. Я создал фиктивный файл изображения, дал ему то же имя и поместил в указанное место.

Запустил скрипт восстановления в третий раз. И вот оно! Мой сайт был восстановлен из резервной копии и обновлён до последней версии.