Problème de mise à niveau de Discourse

Soutien Installation
1

Bonjour,

Je suis en train de mettre à niveau Discourse de la version v2.3.0.beta8 +212 vers la 2.4.0.beta1.

J’ai d’abord mis à niveau le gestionnaire Docker via l’interface web. Ensuite, l’interface m’a indiqué que je devais effectuer la mise à niveau en ligne de commande, ce que j’ai fait.

Je rencontre des erreurs répétées lors de la mise à niveau. J’exécute :

cd /var/discourse
su ./launcher rebuild app

Le processus tourne pendant quelques minutes, puis échoue lors de la mise à niveau de la base de données. J’ai redémarré mon serveur, ce qui a redémarré Discourse (mais sans la mise à niveau), et j’ai réessayé. Même erreur.

Avez-vous des suggestions pour la suite ?

Voici les dernières lignes affichées lors de l’exécution de 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

Édition : Les seules erreurs dans le journal complet sont les suivantes :

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

Je remarque que le processus s’arrête ci-dessus après « Optimizing Site Icons… » — peut-être y a-t-il un problème ici ?

2

Vous pouvez essayer de rechercher « error role discourse already exists »

3

Recherche effectuée avec ce terme, rien trouvé qui ait aidé

  • certains posts mentionnaient des plugins, j’ai désactivé les plugins dans app.yml
  • j’avais un message concernant une version obsolète de Docker, je l’ai mise à niveau
  • j’ai exécuté discourse doctor

mêmes erreurs.

Ci-joint la sortie de launch rebuild.

Des suggestions pour la suite ?

rebuild script.txt (140,9 Ko)

4

Il est à noter que j’ai un root d’URL relative dans mon app.xml. Cela pourrait-il perturber la mise à niveau ?

env:
  DISCOURSE_RELATIVE_URL_ROOT: /epicenter/support

run:
  - exec: echo "Début des commandes personnalisées"

  - 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

Enfin, j’ai réussi à faire fonctionner cela lors de ma troisième ou quatrième session de travail. Le problème semblait provenir d’images manquantes dans le dossier « uploads ». La solution a été de créer une nouvelle installation, d’utiliser le même fichier « app.yml » et de restaurer à partir d’une sauvegarde en ajoutant des fichiers factices pour les images manquantes.

Parallèlement au problème initial, j’ai remarqué qu’après une précédente mise à niveau, diverses icônes et images avaient disparu. Lorsque j’ai tenté de reconstruire, les journaux ont indiqué que le processus s’arrêtait après « optimisation des images du site ». Je pense qu’il a dû se bloquer sur une image manquante et s’est arrêté sans consigner cette erreur spécifique. (il n’y avait aucune indication que des images manquantes étaient le problème, ni quels fichiers d’image étaient absents).

Finalement, j’ai effectué une nouvelle installation de Discourse avec la dernière version. J’ai restauré à partir d’une sauvegarde en suivant les instructions ici. Il m’a fallu trois tentatives.

D’abord, le script de sauvegarde a échoué en cherchant des fichiers téléchargés, alors j’ai copié le dossier uploads/default depuis mes fichiers de sauvegarde précédents.

J’ai exécuté à nouveau le script de restauration. Cette fois, il a signalé une erreur indiquant qu’il ne pouvait pas trouver un fichier image spécifique. J’ai créé un faux fichier image, lui ai donné le même nom et l’ai placé à l’endroit spécifié.

J’ai lancé le script de restauration pour la troisième fois. Et voilà ! Mon site a été restauré à partir de la sauvegarde et est maintenant sur la dernière version.