Problem beim Upgrade von Discourse

Unterstützung Installation
1

Hallo,

ich aktualisiere Discourse von v2.3.0.beta8 +212 auf 2.4.0.beta1.

Zuerst habe ich den Docker-Manager über die Web-Oberfläche aktualisiert. Anschließend teilte mir die Web-Oberfläche mit, dass ich das Update über die Kommandozeile durchführen müsse, was ich auch tat.

Bei der Aktualisierung treten wiederholt Fehler auf. Ich führe folgenden Befehl aus:

cd /var/discourse
./launcher rebuild app

Das Skript läuft einige Minuten, schlägt dann jedoch beim Datenbank-Upgrade fehl. Ich habe meinen Server neu gestartet, wodurch Discourse wieder hochgefahren wurde (aber nicht aktualisiert), und habe es erneut versucht. Derselbe Fehler tritt auf.

Haben Sie Vorschläge, wie ich weiter vorgehen soll?

Hier sind die letzten Zeilen, die beim Neustart des Aufbaus ausgegeben werden:

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

Edit: Die einzigen Fehler im vollständigen Log sind folgende:

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

Ich bemerke, dass es oben nach „Optimizing Site Icons…" abbricht – vielleicht liegt hier ein Problem vor?

2

Sie könnten versuchen, nach „error role discourse already exists“ zu suchen.

3

Nach dieser Suche habe ich nichts Hilfreiches gefunden.

  • Einige Beiträge erwähnten Plugins, die ich in app.yml deaktiviert habe.
  • Ich erhielt eine Meldung über eine veraltete Docker-Version und habe diese aktualisiert.
  • Ich habe discourse doctor ausgeführt.

Die gleichen Fehler treten weiterhin auf.

Im Anhang finden Sie die Ausgabe von launch rebuild.

Haben Sie Vorschläge, wie es weitergehen könnte?

rebuild script.txt (140,9 KB)

4

Es ist erwähnenswert, dass ich in meiner app.xml eine relative URL-Root habe. Könnte das den Upgrade-Vorgang stören?

env:
  DISCOURSE_RELATIVE_URL_ROOT: /epicenter/support

run:
  - exec: echo "Beginn der benutzerdefinierten Befehle"

  - 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

Endlich hat es im dritten oder vierten Arbeitssitz funktioniert. Das Problem schien an fehlenden Bildern im Ordner „uploads