Suddenly boot strapping is failing

I didn’t consciously change anything, but today, when just git pull-ed and tried to bootstrap the web_only.yml , its giving errors, after around 90 seconds of bootstrap process started. I’m pasting just the ending lines of the error, if its of any help to diagnose:

/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/bootsnap-1.15.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/bootsnap-1.15.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/railties-7.0.3.1/lib/rails/application.rb:348:in `require_environment!'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/railties-7.0.3.1/lib/rails/application.rb:511:in `block in run_tasks_blocks'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
I, [2022-12-29T10:28:07.806753 #1]  INFO -- : gem install geocoder -v 1.4.4 -i /var/www/discourse/plugins/discourse-locations/gems/3.1.3 --no-document --ignore-dependencies --no-user-install
Successfully installed geocoder-1.4.4
1 gem installed



FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1066 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
9b7ac0c88b42b2aa1eccb9ef291527f4afd8b71861669af66ab79dee5ed82a45

I can’t understand, why its not allowing the bootstrapping of the same yml file, which earlier was successful. My site, though, is working ok.

I couldn’t find any ‘error’ in ‘Discourse-Doctor’ also ( I can only search for the word ‘error’, which wasn’t there in that resulting file of discourse doctor). I’m not an expert though.

Try removing the locations plugin.

4 Likes

You nailed it. I’m able to bootstrap the web container fully ok now.!!! Thanks very much, umpteenth time.


But now all my previous ‘mappings/locations’ of different posts and users have gone away.

Is there any alternative? I know I can, and I should, and I would, search more on that plugins’ topics. But in short, is there any solution to this problem?

1 Like

Time. I’m sure it’ll be fixed in the next week or two.

4 Likes

Yesterday, after disabling the ‘location’ plugin, I was able to rebuild my web_only container ok. But today, even after disabling all plugins one by one, the bootstrapping is still failing.

Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' failed with return #<Process::Status: pid 900 exit 137>
Location of failure: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
bootstrap failed with exit code 137
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
2c5f01d5ca6b216e744e11547b121e64aac0ad5e37d64d2ec5e2f279fe766c6a

ALTHOUGH MY SITE IS WORKING ABSOLUTELY OK.

What can I do about this? Pls guide me in some direction.

You’re unable to rebuild but you can start the app?

1 Like

Yes, the container is already started and website working. But when I go for rebuilding/bootstrapping the same container (web_only), it gives error. Although yesterday, when faced with same problem, disabling ‘location’ plugin allowed me to bootstrap the same successfully, but today, even without making any changes, the same failed.

1 Like

Your site seems to be offline right now. EDIT: Nope, it’s back. Most of it is in Hindi and I can’t read it though.

Just to be sure. You have no plugins in your app.yml file enabled right now? They’re all commented/deleted?

Error code 137 is out of memory.

5 Likes

Might this be a problem?
Does Discourse need more than 4 gb now (even with all plugins off)?
The other 2 wpress sites running on the same droplet/instance are almost dormant.

Could there be an easy solution to this, other than to go for 8 gb ram machine?

Yes, you only have 400MB of memory free, which will not allow Discourse to rebuild. Try bumping it up to 4/5gb, or shutting down the forum before rebuilding and try again.

Assuming that the 400mb free is at idle. Rebuilding is pretty intensive on the system (I’d look it up in Proxmox for my site, but it’s been offline for a bit now), and requires more memory than idling.

Sorry, but I didn’t understand the meaning well. Do you mean that I should further increase it by 4 to 5 GBs? I.e. make it from 4 gb to 8 or 9 gb?

How can I shutdown my forum (i.e. website)?
And
Do you mean that when after increasing my memory, even then I should turn down my website before rebuilding?

Thanks for guiding me.

Try running this in the command line before adding memory.
This is assuming you have a standard install, as well. Make sure you’re in the /var/discourse directory.

./launcher stop app && ./launcher rebuild app && ./launcher start app

1 Like

You’re correct!!

I rebooted my ubuntu server, which allowed me to have around 7 to 800 MBs of free ram on my instance and bootstrapping succeeded. I’d have stop my container before another BS, if another rebuild/bs didn’t succeed after enabling the desired plugins.

But I’m astonished at the new ram demands of the discourse. As the cost of the instance/droplet is almost doubling when I go from 4 to 8gb ram. Which I don’t wish, considering that mine is a very very very small website (perhaps 10 visitors a day). Earlier Discourse’s standard install shown to demand only 1 to 2 gb ram.

Thanks very much for helping me recognizing what was going wrong.

1 Like

If possible I recommend going for the 8gb machine if available. The 2gb machine is meant for smaller forums, and yours seems to have a lot of content.

1 Like

Mine has 4 gb with very few visits as of now. WIll consider going for 8gb (no 6gb is there) in future.

Btw, some articles on google were saying that the amount of free memory doesn’t matter much. As this is kind of wasted memory which is doing nothing. And users should rather go/check for ‘available memory’, which is available if need arises. And in my case, available memory is 1.4 Gb.
image

Again, I hope to be guided in this also, if you please.

1 Like

What is your system doing with 1.4GB available?

1 Like

As the above given screenshot/article tells, ‘available’ includes ‘buffer memory’ etc, which may be ‘available-to-system’ in case need arises. But I’m no expert on these things.

And, I’m still researching on these, (again, I’m no expert). Though my guess is that my other 2 WP websites, which I consider almost dormant, may have something to do with this. Will try turning them off in some free time, and then compare the performance.

For now, my problem of rebuilding is solved, without going for higher resources and paying almost double every month. Thanks to you.

1 Like

So that’s not a good idea.

Also, it would be a good idea to configure some swap.

You can add swap space. Lots of ram is needed for a rebuild. Also, since you see running things other than discourse in the server, more memory is needed than the minimum. Even if the other sites are getting no traffic, having the other web server running uses some memory.

3 Likes