Problème avec la mise à niveau [erreur 137]

Pour l’installation standard, le site a ce journal d’erreurs lors de la dernière mise à niveau :


********************************************************
*** Veuillez patienter, les prochaines étapes peuvent prendre un certain temps ***
********************************************************
Cyclage de la Licorne, pour libérer de la mémoire
Redémarrage du processus de la Licorne : 545
Attente du rechargement de la Licorne.
Attente du rechargement de la Licorne..
Attente du rechargement de la Licorne...
Attente du rechargement de la Licorne....
Attente du rechargement de la Licorne.....
Attente du rechargement de la Licorne......
Attente du rechargement de la Licorne.......
Attente du rechargement de la Licorne........
Attente du rechargement de la Licorne.........
Attente du rechargement de la Licorne..........
Attente du rechargement de la Licorne...........
Attente du rechargement de la Licorne............
Attente du rechargement de la Licorne.............
Attente du rechargement de la Licorne..............
Attente du rechargement de la Licorne...............
Attente du rechargement de la Licorne................
Attente du rechargement de la Licorne.................
Attente du rechargement de la Licorne..................
Attente du rechargement de la Licorne...................
Attente du rechargement de la Licorne....................
Attente du rechargement de la Licorne.....................
Attente du rechargement de la Licorne......................
Attente du rechargement de la Licorne.......................
Utilisation de libv8-node 18.16.0.0 (x86_64-linux)
Utilisation de method_source 1.0.0
Utilisation de thor 1.3.0
Utilisation de zeitwerk 2.6.12
Utilisation de railties 7.0.7
Utilisation de request_store 1.5.1
Utilisation de lograge 0.14.0
Utilisation de logstash-event 1.2.02
Utilisation de logstash-logger 0.26.1
Utilisation de logster 2.13.1
Utilisation de lru_redux 1.1.0
Utilisation de lz4-ruby 0.3.3
Utilisation de maxminddb 0.1.22
Utilisation de memory_profiler 1.0.1
Utilisation de message_bus 4.3.8
Utilisation de mini_racer 0.8.0
Utilisation de redis 4.8.1
Utilisation de sidekiq 6.5.12
Utilisation de mini_scheduler 0.16.0
Utilisation de mini_sql 1.5.0
Utilisation de mini_suffix 0.3.3
Utilisation de multi_json 1.15.0
Utilisation de multi_xml 0.6.0
Utilisation de mustache 1.1.1
Utilisation de uri 0.13.0
Utilisation de net-http 0.4.0
Utilisation de nio4r 2.7.0
Utilisation de version_gem 1.1.3
Utilisation de oauth-tty 1.0.5
Utilisation de snaky_hash 2.0.1
Utilisation de oauth 1.1.0
Utilisation de oauth2 1.4.11
Utilisation de oj 3.16.3
Utilisation de omniauth 1.9.2
Utilisation de omniauth-oauth2 1.7.3
Utilisation de omniauth-facebook 9.0.0
Utilisation de omniauth-github 1.4.0
Utilisation de omniauth-google-oauth2 0.8.2
Utilisation de omniauth-oauth 1.2.0
Utilisation de omniauth-twitter 1.4.0
Utilisation de optimist 3.1.0
Utilisation de pg 1.5.4
Utilisation de pry 0.14.2
Utilisation de pry-byebug 3.10.1
Utilisation de pry-rails 0.3.9
Utilisation de puma 6.4.0
Utilisation de rack-mini-profiler 3.3.0
Utilisation de rack-protection 3.1.0
Utilisation de rails_failover 2.0.1
Utilisation de rails_multisite 5.0.0
Utilisation de raindrops 0.20.1
Utilisation de rbtrace 0.5.1
Utilisation de rchardet 1.8.0
Utilisation de redis-namespace 1.11.0
Utilisation de rexml 3.2.6
Utilisation de rinku 2.0.6
Utilisation de rotp 6.3.0
Utilisation de rqrcode_core 1.2.0
Utilisation de rqrcode 2.2.0
Utilisation de rss 0.3.0
Utilisation de rtlcss 0.2.1
Utilisation de ruby-readability 0.7.0
Utilisation de rubyzip 2.3.2
Utilisation de sanitize 6.1.0
Utilisation de sass-embedded 1.69.5 (x86_64-linux-gnu)
Utilisation de sassc-embedded 1.68.6
Utilisation de sprockets 3.7.2 depuis https://github.com/rails/sprockets (à 3.x@f4d3dae)
Utilisation de sprockets-rails 3.4.2
Utilisation de sshkey 3.0.0
Utilisation de stackprof 0.2.25
Utilisation de tzinfo-data 1.2023.4
Utilisation de uglifier 4.2.0
Utilisation de unicorn 6.1.0
Utilisation de web-push 3.0.1
Bundle complet ! 138 dépendances de Gemfile, 171 gems installées.
Les gems des groupes 'development' et 'test' n'ont pas été installées.
Les gems groupées sont installées dans `./vendor/bundle`
1 gem installée dont vous dépendez directement recherche un financement.
  Exécutez `bundle fund` pour plus de détails
$ yarn install
yarn install v1.22.19
[1/5] Validation de package.json...
[2/5] Résolution des paquets...
succès Déjà à jour.
$ yarn --cwd app/assets/javascripts $(node -e 'const argv = JSON.parse(process.env.npm_config_argv).original; const passthrough = [`--frozen-lockfile`, `-s`].filter(arg => argv.includes(arg)); console.log(passthrough.join(` `));')
yarn install v1.22.19
[1/4] Résolution des paquets...
avertissement Le champ de résolution "unset-value@2.0.1" est incompatible avec la version demandée "unset-value@^1.0.0"
succès Déjà à jour.
$ ./run-patch-package
patch-package 8.0.0
Application des correctifs...
babel-plugin-debug-macros@0.3.4 ✔
content-tag@1.2.2 ✔
ember-cli@5.0.0 ✔
ember-this-fallback@0.4.0 (1 deprecation-name) ✔
ember-this-fallback@0.4.0 (2 themes) ✔
virtual-dom@2.1.1 ✔
Terminé en 4.79s.
Terminé en 7.25s.
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
docker_manager est déjà à la dernière version compatible
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Le migrator multisite s'exécute en utilisant 1 thread
Migration de default
Initialisation de default
*** Compilation des assets. Cela prendra un certain temps ***
$ bundle exec rake themes:update assets:precompile
Vérification de 'Air Theme' pour 'default'... mise à jour de b9d44745 à 85dc24d6
Vérification de 'Modern Category + Group Boxes' pour 'default'... à jour
Vérification de 'Discourse Clickable Topic' pour 'default'... à jour
Vérification de 'discourse-search-banner' pour 'default'... mise à jour de 934e0d35 à 6ba0e9d0
La limite de taille du tas Node.js (488.25) est inférieure à 2048 Mo. Définition de --max-old-space-size=2048.
yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Construction
Environnement : development
AVERTISSEMENT : ember-test-selectors : vous utilisez une version non prise en charge de ember-cli-babel. Les propriétés data-test ne sont pas automatiquement supprimées de votre code JS.
construction...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: discourse-widget-hbs > applyPatches]
...[Babel: ember-source > applyPatches]
...[ember.js]
...[Babel: discourse-common > applyPatches]
...[Babel: truth-helpers > applyPatches]
...[Babel: ember-tracked-storage-polyfill > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: @ember/render-modifiers > applyPatches]
...[Babel: @ember/test-helpers > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: @embroider/util > applyPatches]
...[Babel: @glimmer/component > applyPatches]
...[Babel: dialog-holder > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-buffered-proxy > applyPatches]
...[Babel: ember-cached-decorator-polyfill > applyPatches]
...[Babel: ember-exam > applyPatches]
...[Babel: ember-functions-as-helper-polyfill > applyPatches]
...[Babel: ember-load-initializers > applyPatches]
...[Babel: ember-on-resize-modifier > applyPatches]
...[Babel: ember-resize-observer-service > applyPatches]
...[Babel: ember-router-service-refresh-polyfill > applyPatches]
...[Babel: float-kit > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
Killed
error La commande a échoué avec le code de sortie 137.
info Visitez https://yarnpkg.com/en/docs/cli/run pour la documentation sur cette commande.
Docker Manager : ÉCHEC DE LA MISE À NIVEAU
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.7/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.7/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.0/lib/thor.rb:527:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.7/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.7/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.7/lib/rails/commands.rb:18:in `<main>'
/internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.17.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Lancement de 1 worker Unicorn qui ont été arrêtés initialement

Il semble toujours fonctionner pour traiter la mise à niveau, je ne suis pas sûr s’il s’agit d’un problème grave ou de ce qui peut être fait à ce sujet.

Hors de mémoire.
Vous devrez ajouter du swap ou de la RAM.
Mais vous pouvez aussi réessayer et cela pourrait fonctionner.
Si vous mettez à jour depuis l’UX, vous devriez essayer une reconstruction en ligne de commande.

5 « J'aime »

J’ai rencontré le même problème avec 1 Go de RAM et 2 Go de swap (mise à niveau depuis l’interface web). J’ai augmenté le swap à 3 Go, jusqu’à présent, il semble que cela va fonctionner cette fois (mise à niveau depuis la CLI).

3 « J'aime »

Merci, oui c’est un serveur avec 1 Go de mémoire, ce qui ne semble plus idéal pour Discourse, il en faut 2 pour que cela fonctionne correctement. La mise à jour d’installation fonctionne peut-être maintenant après redémarrage, on verra si elle se termine.

Non, échec à nouveau. Cela provenait de l’UX, j’essaierai la ligne de commande ensuite.

Quelle quantité de RAM et de swap possédez-vous ?

free -h

Les mises à jour en ligne nécessitent au moins 4 Go de nos jours, d’après mon expérience (on peut s’en sortir avec 3…).

Indique 952 Mo de mémoire et 2,0 Gio d’espace d’échange. Je ne sais pas ce qu’est l’espace d’échange ?

Les mises à niveau semblent avoir fonctionné depuis la ligne de commande apt upgrade

Voulez-vous dire que pour pouvoir exécuter des mises à jour via l’interface utilisateur, vous avez idéalement besoin de 4 Go pour que cela fonctionne ?

Je ne sais pas pourquoi cela consomme plus de mémoire que la ligne de commande.

J’ai deux sites d’installation standard sur DigitalOcean, le coût total pour ces deux sites est de 16,32 par mois, ce qui est beaucoup moins que de payer 100 par mois pour un site standard hébergé, mais jusqu’à présent, je n’ai eu aucune inscription pour ceux-ci, donc c’est du gaspillage à moins que les gens ne veuillent s’inscrire, ils pourraient fermer ces sites.

Cela ne semble pas correct. Qu’essayez-vous de faire ?

Connecté à la console en tant que root, je tape la commande « apt upgrade » et cela lance l’installation de la mise à niveau.

Merci à @Arkshine d’en avoir parlé ici :

Je ne sais pas ce que signifie « Apt », mais cela semble nécessaire pour que cela fonctionne.

Pour vérifier, supposez-vous que vous mettez à niveau votre Discourse ou votre serveur ?

J’avais bien pensé avoir mis à niveau Discourse, mais c’était peut-être plutôt le serveur Ubuntu qui était mis à niveau, je ne suis pas sûr.

Je pense que vous pourriez bénéficier de la lecture de quelques sujets supplémentaires sur le sujet. Si vous effectuez une recherche dans la Documentation, ou simplement une recherche en général, je pense que vous trouverez de nombreuses informations qui devraient vous aider à combler les lacunes de vos connaissances. Il existe une quantité substantielle de conseils qui couvrent les bases à partir desquelles vous pouvez apprendre. :+1:

2 « J'aime »

Ok, beaucoup à apprendre pour ça.

2 « J'aime »

J’ai manqué que vous ayez écrit reconstruction peut reconstruire l’application.

Voici le guide officiel :

Parce que l’exécution du site web (bien qu’avec moins de Licornes) + l’exécution d’une compilation en même temps coûte cher en mémoire ?

J’ai essayé cela sur mon serveur (3 VCPU, 4 Go) :

En ligne :

2,21 avant la mise à niveau → 1,7 car cela libère de la mémoire → pic de 3,5 pendant la compilation (Go)

Le swap a également augmenté d’environ 200 Mo pour atteindre un pic d’environ 800 Mo.

Ligne de commande (pas comparable car juste après ce qui précède)

1,7 avant la mise à niveau → descend à ~250 Mo ! → monte et monte jusqu’à un pic de 3,25 pendant la compilation des actifs, mais généralement beaucoup plus bas.

L’utilisation du swap a été très faible pendant presque tout le processus.

Mise en garde : tous les chiffres observés dans htop peuvent donc être inexacts, il est probablement préférable de les représenter graphiquement.

J’ai été surpris de voir à quel point les reconstructions hors ligne étaient “pics”. La précompilation des actifs utilise certainement beaucoup de mémoire - peut-être plus vous avez de VCPU car elle pourrait en faire en parallèle ?

J’ai également été surpris de la faible différence de pic dans mon cas, bien que l’utilisation du swap ait été considérablement plus faible et, en général, l’utilisation de la mémoire était beaucoup plus faible pour une reconstruction hors ligne, restant dans les centaines de Mo pendant 95 % du processus, alors qu’une mise à niveau en ligne était au minimum de 1,7 Go.

2 « J'aime »

Cela semble correct, pas besoin de point d’interrogation là !

Donc, reconstruire l’application met automatiquement à jour vers la version la plus récente, semble-t-il ?

Existe-t-il un moyen pris en charge ou non pris en charge de conserver les versions précédentes de Discourse en cours d’exécution, ou de faire de nouvelles installations pour les versions précédentes ?

Non, mais vous pouvez ralentir les choses en passant à stable.

Malheureusement, vous avez raté le coche cette fois-ci car vous ne pouvez pas revenir en arrière.

Ok, vous voudrez peut-être passer à ce réglage stable pour uniquement les mises à jour stables testées, pas celles pour les développeurs/bêtas. Je cherche à savoir comment faire.

1 « J'aime »