Discourse Docker Manager

[Discourse]

	Summary	Provides basic monitoring and update facilities to Discourse instances hosted using our Docker template: GitHub - discourse/discourse_docker: A Docker image for Discourse
	Repository Link	GitHub - discourse/docker_manager: Plugin for use with discourse docker image
	Install Guide	This plugin is included by default in all standard installs

As this is an official plugin maintained by the Discourse team, support, bug, ux, and feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Click on a link below to get one started.

 Support  Bug  UX  Feature

[JammyDodger]

Just to cross-link this here for extra visibility:

New change: upgrade page is now the update page!

With the PRs below, the “Upgrade” admin page has been renamed to “Update”. The reason for this is to differentiate the update process in self-hosted sites from the plan “upgrade” process in hosted sites. By updating your self-hosted site you are getting the latest code, not upgrading your plan to get more features. You will see the rename everywhere in the UI where “upgrade” previously showed up. If you notice any places we missed or any other issues with this change, let us know! I noticed wh…

[Milenski (Milen Valov)]

ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod Docker Manager: FAILED TO UPGRADE

After each update attempt…

[NateDhaliwal]

Could you post the full logs? Thanks!

[Canapin (Coin-coin le Canapin)]

@Milenski

Command was killed with SIGKILL

I think I got this issue when having no swap and fixed it by adding swap.

Edit, this corroborates my suggestion:

Failed new install

I think this means that it took too long. I would try adding swap and/or ram. I could try reading the other posts before I say the same thing that everyone else did.

[Milenski (Milen Valov)]

@Canapin

I think I got this issue when having no swap and fixed it by adding swap.

Edit, this corroborates my suggestion:

I might try even though my machine has 4GB of free RAM If it really takes too long, could it be because of Cloudflare?

@NateDhaliwal

Could you post the full logs? Thanks!

I’ve updated my other server and we’ll see if this error occurs again, I’ll post some of the logs.

And the part of the log…

== 20250313045010 AddIndexToUsersIpAddress: migrating =========================
-- remove_index(:users, :ip_address, {:algorithm=>:concurrently, :name=>"idx_users_ip_address", :if_exists=>true})
   -> 0.0310s
-- add_index(:users, :ip_address, {:algorithm=>:concurrently, :name=>"idx_users_ip_address"})
   -> 0.0161s
== 20250313045010 AddIndexToUsersIpAddress: migrated (0.0492s) ================

Seeding default
*** Bundling assets. This will take a while *** 
$ bundle exec rake themes:update assets:precompile
Updating themes with concurrency: 10
Node.js heap_size_limit (2010.75) is less than 2048MB. Setting --max-old-space-size=2048 and CHEAP_SOURCE_MAPS=1
Building
Environment: production
The setting 'staticAddonTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTrees: true' in your Embroider config.
The setting 'staticAddonTestSupportTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTestSupportTrees: true' in your Embroider config.
building...
...[ConfigLoader]
...[Babel: discourse-widget-hbs > applyPatches]
...[Babel: @embroider/macros > applyPatches]
...[Babel: ember-tracked-storage-polyfill > applyPatches]
...[Babel: pretty-text > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js as it exceeds the max of 500KB.
[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js as it exceeds the max of 500KB.
...[Babel: ember-source > applyPatches]
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/render-modifiers > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: dialog-holder > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-buffered-proxy > applyPatches]
...[Babel: ember-cache-primitive-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]
undefined
 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL  Command was killed with SIGKILL (Forced termination): ember build -prod
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112: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.3.0/gems/railties-7.2.2.1/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.3.2/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.3.2/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.3.2/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/command.rb:71:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/command.rb:149:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/command.rb:69:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Spinning up 7 Unicorn worker(s) that were stopped initially

Is it possible that this error occurs because of the Ubuntu version?

The problem is in the server. On my third server it worked without a problem, but apparently on my other two servers it may say they have 4GB of RAM, but they clearly don’t have that much…