Another discourse offline "bootstrap failed with exit code 5"

Installation
1

Hello Community! I’m sorry we have to meet under these circumstances. Discourse is offline after a failed upgrade.

Same story as.

Discourse offline after failed upgrade "bootstrap failed with exit code 5"

Attempted to upgrade to v3.2.0.beta3

I’m still on Ubuntu 16.04.

I DO have the previous docker images fortunately (I hope), but I’m not sure what to do to restore services. Also using DigitalOcean.

Error

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --retry 3 --jobs 4' failed with return #<Process::Status: pid 448 exit 5>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle config --local deployment true'", "su discourse -c 'bundle config --local without \"development test\"'", "su discourse -c 'bundle install --retry 3 --jobs 4'"]}
bootstrap failed with exit code 5
** 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.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261

Can anyone help?

2

While I have the old images, I did remove the newest image…

docker rmi 51421f454322 -f

I have the old containers, but when I attempt to run ./launcher start app, it appears to prefer that deleted image.

root@hostname:/var/discourse# ./launcher start app
WARNING: Docker version 17.05.0-ce deprecated, recommend upgrade to 17.06.2 or newer.
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml

starting up existing container
+ /usr/bin/docker start app
app

root@hostname:/var/discourse# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                      NAMES
afeec2777503        51421f454322        "/sbin/boot"        3 hours ago         Up 5 seconds        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
root@hostname:/var/discourse# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
discourse/base      2.0.20231218-0429   984f729957df        12 days ago         3.14GB

Is there a way to proceed with image id 984f729957df?

3

The easier thing is to go ahead and spin up a new droplet and copy /var/discourse to it and rebuild there. That will solve the problem rather than mitigate it.

There is a launcher command that will give you the docker command which might help. You can look at the launcher script to find its name (but I’m on my phone).

1 Like
4

Looks like you’re suggesting: ./launcher start-cmd app

It outputs quite a bit, starting with + true run --shm-size=512m -d --restart=always...

Going out on a limb, I tried:
docker + true run 984f729957df --shm-size=512m -d --restart=always ... to no avail.

container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH".

Any help you can provide is welcome. Thank you.

5

Yeah. Something like that. I don’t know how to do it. You might have deleted the only usable image.

My recommendation remains to spin up a new droplet and copy stuff over. If you were one of my clients, that’s what I’d do.

6

Thanks for the suggestion. Not a fan of unplanned migrations, but it seems like that’s in the cards. I’m gonna presume that you’re referring to this? Move a Discourse site to another VPS with rsync

Will there be any extra instructions if we’ve enabled DO Spaces (S3 storage)?

Given the time of the year, it’s going to be really difficult (read: probably impossible) to coordinate the others for the needed changes in a timely manner.

I’d much rather revert to the state it was last working first so that I can plan a migration, instead.

Can anyone help?

7

Not if you followed Configure an S3 compatible object storage provider for uploads. If you have the settings in the database it might be more complicated if you try to do a restore rather than rsync.

Moving to a new droplet is low risk since you can just change dns back to your disabled site, but if you don’t have access to dns and digital ocean you’re stuck.

Sounds like maybe you missed quoting something with the start command. Sounds like that might be what you want to do.

Good luck

8

Configure an S3 compatible object storage provider for uploads

I configured this service in 2016, so unfortunately it would appear that we have the settings in a db? There are no S3 params in app.yml

Any other landmines I should be made aware of?

9

If you rsync it over, you should be fine. Then you can switch over to the recommended setup. You might have trouble if your try a database restore.

1 Like
10

Thanks again for your assist. As for the rsync, I am a little worried with how the instructions state in so many words:

  1. setup the new server and sync
  2. stop the service on the old server
  3. sync again but with --delete

That sounds volatile, and also not possible in my scenario. Will that be a concern? I feel like it’s just about making sure anything that happened since the last rsync on the forum gets synced but I could be wrong.

11

Update:
We’re back online with a whole new Droplet.

I’m glad I know now that a migration is relatively straightforward. Would have been a lot cooler if the update didn’t break the old droplet.

I know it’s a holiday, but it’d be great if someone on the dev team could spend some time looking into this. I don’t think this is a one-off. I got tagged on another thread where a collection has been growing.

2 Likes