Problema con la actualización [error 137]

[anon36555649]

Para la instalación estándar, el sitio tiene este registro de errores para la actualización más reciente:

********************************************************
*** Por favor, sea paciente, los próximos pasos pueden tardar ***
********************************************************
Ciclado de Unicorn, para liberar memoria
Reiniciando unicorn pid: 545
Esperando a que Unicorn se recargue.
Esperando a que Unicorn se recargue..
Esperando a que Unicorn se recargue...
Esperando a que Unicorn se recargue....
Esperando a que Unicorn se recargue.....
Esperando a que Unicorn se recargue......
Esperando a que Unicorn se recargue.......
Esperando a que Unicorn se recargue........
Esperando a que Unicorn se recargue.........
Esperando a que Unicorn se recargue..........
Esperando a que Unicorn se recargue...........
Esperando a que Unicorn se recargue............
Esperando a que Unicorn se recargue.............
Esperando a que Unicorn se recargue..............
Esperando a que Unicorn se recargue...............
Esperando a que Unicorn se recargue................
Esperando a que Unicorn se recargue.................
Esperando a que Unicorn se recargue..................
Esperando a que Unicorn se recargue...................
Esperando a que Unicorn se recargue....................
Esperando a que Unicorn se recargue.....................
Esperando a que Unicorn se recargue......................
Esperando a que Unicorn se recargue.......................
Usando libv8-node 18.16.0.0 (x86_64-linux)
Usando method_source 1.0.0
Usando thor 1.3.0
Usando zeitwerk 2.6.12
Usando railties 7.0.7
Usando request_store 1.5.1
Usando lograge 0.14.0
Usando logstash-event 1.2.02
Usando logstash-logger 0.26.1
Usando logster 2.13.1
Usando lru_redux 1.1.0
Usando lz4-ruby 0.3.3
Usando maxminddb 0.1.22
Usando memory_profiler 1.0.1
Usando message_bus 4.3.8
Usando mini_racer 0.8.0
Usando redis 4.8.1
Usando sidekiq 6.5.12
Usando mini_scheduler 0.16.0
Usando mini_sql 1.5.0
Usando mini_suffix 0.3.3
Usando multi_json 1.15.0
Usando multi_xml 0.6.0
Usando mustache 1.1.1
Usando uri 0.13.0
Usando net-http 0.4.0
Usando nio4r 2.7.0
Usando version_gem 1.1.3
Usando oauth-tty 1.0.5
Usando snaky_hash 2.0.1
Usando oauth 1.1.0
Usando oauth2 1.4.11
Usando oj 3.16.3
Usando omniauth 1.9.2
Usando omniauth-oauth2 1.7.3
Usando omniauth-facebook 9.0.0
Usando omniauth-github 1.4.0
Usando omniauth-google-oauth2 0.8.2
Usando omniauth-oauth 1.2.0
Usando omniauth-twitter 1.4.0
Usando optimist 3.1.0
Usando pg 1.5.4
Usando pry 0.14.2
Usando pry-byebug 3.10.1
Usando pry-rails 0.3.9
Usando puma 6.4.0
Usando rack-mini-profiler 3.3.0
Usando rack-protection 3.1.0
Usando rails_failover 2.0.1
Usando rails_multisite 5.0.0
Usando raindrops 0.20.1
Usando rbtrace 0.5.1
Usando rchardet 1.8.0
Usando redis-namespace 1.11.0
Usando rexml 3.2.6
Usando rinku 2.0.6
Usando rotp 6.3.0
Usando rqrcode_core 1.2.0
Usando rqrcode 2.2.0
Usando rss 0.3.0
Usando rtlcss 0.2.1
Usando ruby-readability 0.7.0
Usando rubyzip 2.3.2
Usando sanitize 6.1.0
Usando sass-embedded 1.69.5 (x86_64-linux-gnu)
Usando sassc-embedded 1.68.6
Usando sprockets 3.7.2 de https://github.com/rails/sprockets (en 3.x@f4d3dae)
Usando sprockets-rails 3.4.2
Usando sshkey 3.0.0
Usando stackprof 0.2.25
Usando tzinfo-data 1.2023.4
Usando uglifier 4.2.0
Usando unicorn 6.1.0
Usando web-push 3.0.1
¡Bundle completo! 138 dependencias de Gemfile, 171 gems instaladas ahora.
Las gems en los grupos 'development' y 'test' no fueron instaladas.
Las gems empaquetadas se instalan en `./vendor/bundle`
1 gema instalada de la que dependes directamente está buscando financiación.
  Ejecuta `bundle fund` para más detalles
$ yarn install
yarn install v1.22.19
[1/5] Validando package.json...
[2/5] Resolviendo paquetes...
Éxito. Ya está actualizado.
$ 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] Resolviendo paquetes...
advertencia El campo de resolución "unset-value@2.0.1" es incompatible con la versión solicitada "unset-value@^1.0.0"
Éxito. Ya está actualizado.
$ ./run-patch-package
patch-package 8.0.0
Aplicando parches...
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 ✔
Hecho en 4.79s.
Hecho en 7.25s.
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
docker_manager ya está en la última versión compatible
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
El migrador multisite se está ejecutando usando 1 hilos
Migrando default
Sembrando default
*** Empaquetando assets. Esto llevará un tiempo ***
$ bundle exec rake themes:update assets:precompile
Comprobando 'Air Theme' para 'default'... actualizando de b9d44745 a 85dc24d6
Comprobando 'Modern Category + Group Boxes' para 'default'... actualizado
Comprobando 'Discourse Clickable Topic' para 'default'... actualizado
Comprobando 'discourse-search-banner' para 'default'... actualizando de 934e0d35 a 6ba0e9d0
El límite de tamaño de montón de Node.js (488.25) es inferior a 2048 MB. Estableciendo --max-old-space-size=2048.
yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Construyendo
Entorno: development
ADVERTENCIA: ember-test-selectors: Estás usando una versión no compatible de ember-cli-babel. Las propiedades data-test no se eliminan automáticamente de tu código JS.
construyendo...
...[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 El comando falló con el código de salida 137.
info Visita https://yarnpkg.com/en/docs/cli/run para obtener documentación sobre este comando.
Docker Manager: FALLO AL ACTUALIZAR
#<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>'
Iniciando 1 worker(s) de Unicorn que fueron detenidos inicialmente

Parece que todavía está funcionando para procesar la actualización, no estoy seguro de si esto es un problema grave o qué se puede hacer al respecto.

[pfaffman (Jay Pfaffman)]

@anon36555649

exit code 137

Sin memoria.

Necesitarás añadir swap o RAM.

Pero también puedes intentarlo de nuevo y podría funcionar.

Si estás actualizando desde la UX, deberías intentar una reconstrucción desde la línea de comandos.

[zoul (Tomáš Znamenáček)]

Me encontré con el mismo problema con 1 GB de RAM y 2 GB de intercambio (actualizando desde la interfaz web). Aumenté el intercambio a 3 GB, hasta ahora parece que funcionará esta vez (actualizando desde la CLI).

[anon36555649]

Gracias, sí, este es un servidor con 1 GB de memoria, parece que ya no es ideal para Discourse, necesita 2 para funcionar correctamente. La instalación de la actualización puede estar funcionando ahora después de reiniciar, veremos si se completa.

[anon36555649]

No, falló de nuevo. Esto fue desde UX, intentaré con la línea de comandos a continuación.

[pfaffman (Jay Pfaffman)]

¿Cuánta RAM y swap tienes?

free -h

[merefield (Robert)]

@anon36555649

Gracias, sí, este es un servidor con 1 GB de memoria, parece que ya no es ideal para Discourse, necesita 2 para funcionar correctamente. La instalación de la actualización puede estar funcionando ahora después de reiniciar, veremos si se completa.

Las actualizaciones en línea, en mi experiencia, requieren al menos 4 GB hoy en día (podrías arreglártelas con 3…)

[anon36555649]

Dice 952 Mi de memoria y 2.0 Gi de swap. ¿No sé qué es swap?

Las actualizaciones parecieron funcionar desde la línea de comandos apt upgrade

[anon36555649]

¿Con eso te refieres a que para poder ejecutar actualizaciones a través de la UX necesitas idealmente 4 GB para que funcione?

No sé por qué eso consume más memoria que la línea de comandos.

Tengo dos sitios de instalación estándar en Digital Ocean, el costo total para ambos es de $16.32 al mes, esto es mucho menos que pagar los $100 al mes por un sitio estándar alojado, pero hasta ahora no he tenido ningún registro para esos, así que esto es un desperdicio a menos que la gente quiera unirse, puede que cierre esos sitios.

[JammyDodger]

@anon36555649

Las actualizaciones parecieron funcionar desde la línea de comandos apt upgrade

Esto no parece correcto. ¿Qué intentas hacer?

[anon36555649]

En la consola, conectado como root, escribo el comando “apt upgrade” y esto inicia la instalación de la actualización.

Gracias a @Arkshine por mencionarlo aquí:

How to install updates with console

Hello, For server updates, you can use apt upgrade with Ubuntu. As a side note, this is not directly related to Discourse. With a standard installation, Discourse would be inside a Docker container.

No sé qué significa “Apt”, pero parece ser necesario para que esto funcione.

[JammyDodger]

Solo para comprobar, ¿asume que está actualizando su Discourse o su servidor?

[anon36555649]

Bueno, había pensado que se había actualizado Discourse, pero quizás fue el servidor Ubuntu el que se estaba actualizando, no estoy seguro.

[JammyDodger]

Creo que te beneficiarías de leer más temas sobre el tema. Si buscas en la #documentación, o simplemente buscas en general, creo que encontrarás mucha información que debería ayudarte a llenar los vacíos en tu conocimiento. Hay una cantidad sustancial de consejos que cubren lo básico del que puedes aprender.

[anon36555649]

Ok, mucho que aprender para esto.

[anon36555649]

@pfaffman

reconstrucción de línea de comandos

Me perdí que escribiste reconstrucción puede reconstruir la aplicación.

Aquí está la guía oficial:

Manually update Discourse and Docker image to latest

This guide provides step-by-step instructions for manually updating Discourse, the Docker container, and the Ubuntu operating system on a self-hosted setup. Required user level: System Administrator SSH access to the server. If you self-host Discourse, you occasionally need to run a manual update via the command line to get the latest security releases newest libraries. These updates are not picked up in admin/update, which is why you’ll occasiona…

[merefield (Robert)]

¿Porque ejecutar el sitio web (aunque con menos Unicorns) + realizar una compilación al mismo tiempo es costoso en memoria?

Probé esto en mi servidor (3 VCPU, 4GB):

En línea:

2.21 antes de la actualización → 1.7 ya que libera memoria → 3.5 pico durante la compilación (GB)

El intercambio también aumentó ~200MB hasta un pico de ~800MB

Línea de comandos (no es comparable ya que es justo después de lo anterior)

1.7 antes de la actualización → ¡baja a ~250MB! → sube y sube hasta un pico de 3.25 durante la compilación de activos, pero en general mucho más bajo.

El uso del intercambio fue muy bajo durante casi todo el proceso.

Advertencia: todas las cifras observadas en htop pueden ser inexactas, probablemente sea mejor graficarlas.

Me sorprendió lo “pico” que fueron las reconstrucciones sin conexión. La precompilación de activos definitivamente usa mucha memoria, ¿quizás más cuantos más VCPUs tengas, ya que podría hacer algo de eso en paralelo?

También me sorprendió la poca diferencia que hubo en el pico en mi caso, aunque el uso del intercambio fue significativamente menor y, en general, el uso de memoria fue mucho menor para una reconstrucción sin conexión, manteniéndose en cientos de MB durante el 95% del proceso, mientras que una actualización en línea fue como mínimo de 1.7 GB.

[anon36555649]

@merefield

¿Porque ejecutar el sitio web (aunque con menos Unicornios) + realizar una compilación al mismo tiempo es costoso en memoria?

¡Eso parece correcto, no hay necesidad de un signo de interrogación ahí!

Entonces, ¿recompilar la aplicación la actualiza automáticamente a la versión más reciente?

¿Existe una forma compatible o no compatible de mantener funcionando versiones anteriores de Discourse, o se realizan nuevas instalaciones para versiones anteriores?

[merefield (Robert)]

No, pero puedes ralentizar las cosas cambiando a stable.

Lamentablemente, esta vez te has perdido el barco, ya que no puedes retroceder.

[anon36555649]

Ok, puede que quieras cambiar a esa configuración estable solo para actualizaciones estables probadas, no para las de desarrollador/beta. Estoy buscando cómo hacerlo.