Latest rebuild broken

I have a long running system, never had any problems before. I always upgrade using a full rebuild, never using the built-in upgrade.

I recently did an apt-get upgrade, docker upgrade to 19.03.5 and tried a rebuild but it’s now broken. System is Ubuntu 16.04.6.

Here is my rebuild snippet:

cd /var/discourse || exit
sudo git pull
sudo docker stop maphub_forum
sudo docker rm maphub_forum
sudo ./launcher rebuild maphub_forum

Here is the full log:
diag.txt (518.9 KB)

3 Likes

I downgraded to Docker 18.09.9 and the problem is the same.

1 Like

@joffreyjaffeux Should Discourse.redis be backported to stable and beta? I guess that would be easier than adding code for backwards compatibility to multiple plugins.

2 Likes

Yes I was hoping it wouldnt cause too much issues , but yes probably. It’s multiple commits though.

1 Like

I backported to beta and stable, let me know if you encounter any issue.

4 Likes

@joffreyjaffeux Now I cant update from dashboard:

/var/www/discourse/plugins/docker_manager/lib/docker_manager/git_repo.rb:23:in `upgrade_version'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/git_repo.rb:27:in `upgrading?'
/var/www/discourse/plugins/docker_manager/app/controllers/docker_manager/admin_controller.rb:42:in `block in repos'
/var/www/discourse/plugins/docker_manager/app/controllers/docker_manager/admin_controller.rb:29:in `map!'
/var/www/discourse/plugins/docker_manager/app/controllers/docker_manager/admin_controller.rb:29:in `repos'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/abstract_controller/base.rb:196:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/rendering.rb:30:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/abstract_controller/callbacks.rb:42:in `block in process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/callbacks.rb:135:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/abstract_controller/callbacks.rb:41:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/rescue.rb:22:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/instrumentation.rb:33:in `block in process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/instrumentation.rb:32:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal/params_wrapper.rb:245:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.1/lib/active_record/railties/controller_runtime.rb:27:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/abstract_controller/base.rb:136:in `process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionview-6.0.1/lib/action_view/rendering.rb:39:in `process'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-mini-profiler-1.1.3/lib/mini_profiler/profiling_methods.rb:104:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal.rb:191:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_controller/metal.rb:252:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/route_set.rb:51:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/route_set.rb:33:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/mapper.rb:18:in `block in <class:Constraints>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/mapper.rb:48:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:49:in `block in serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:32:in `each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:32:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/route_set.rb:837:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:526:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/mapper.rb:19:in `block in <class:Constraints>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/mapper.rb:48:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:49:in `block in serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:32:in `each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/journey/router.rb:32:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/routing/route_set.rb:837:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.7/lib/rack/protection/frame_options.rb:31:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/tempfile_reaper.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/conditional_get.rb:25:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/head.rb:12:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:274:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:232:in `context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:226:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/cookies.rb:648:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/callbacks.rb:101:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/actionable_exceptions.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/debug_exceptions.rb:32:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.4.1/lib/logster/middleware/reporter.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/rack/logger.rb:38:in `call_app'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:18:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/method_override.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/executor.rb:14:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/sendfile.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/host_authorization.rb:77:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-mini-profiler-1.1.3/lib/mini_profiler/profiler.rb:296:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-2.2.3/lib/message_bus/rack/middleware.rb:57:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:176:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:526:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:68:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:605:in `process_client'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:700:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:548:in `spawn_missing_workers'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:144:in `start'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

Thanks, it works perfect now!

3 Likes

Is this problem even related to the new update?

You need to rebuild the container.

cd /var/discourse
git pull
./launcher rebuild app

I’m quite sure the latest changes break docker_manager as it gets updated before Discourse and thus doesn’t find Discourse.redis.

4 Likes

But git pull; ./launcher rebuild app does the trick, right?

I have a set of clients that I do upgrades for when a new container image is released. I usually do those upgrades soon after (1) a new container is required and (2) a new beta has been released.

I know that your ability to reliably predict the future is somewhat limited, but do you anticipate that there will be a new beta release soon?

2 Likes

We expect to have a beta release today or beginning next week

4 Likes

It broke down again. Full log after git pull + rebuild:

discourse.txt (24.4 KB)

1 Like

The “stable” branch is currently broken.

4 Likes

Short summary: tests-passed worked, I had a downtime of 1 day

Longer version: I think this is one of the highest quality open source software written on the internet today, with a solid business model and a great team. How come the upgrade mechanism is just so broken?

  1. The in-app upgrade feature gave me so many downtime that I decided not to use it at all, but always do a rebuild.
  2. But as you can see from this thread 2 out of 2 times recently the rebuild also gave a very broken app, something which I could not possibly fix on my own, other than going to “tests-passed” based on recommendations here.

Why is the upgrade mechanism so broken in such a well written software? Why is it that I have 5+ year Wordpress sites working without any problem with build-in upgrade mechanism?

What is the point of having releases in Discourse if there is literally no way to use them? A rebuild is always from a git branch and releases don’t have anything to do with git at all.

For me a release would be either a git tag or a zip file. Why can I not just use rebuild with 2.3.x, like I could do with any modern package manager today?

As it turns out, tests-passed is what discourse.org deploys on their servers and it is better tested and more reliable than stable. If you stay on tests-passed you’ll have fewer problems. If you want to run stable then you need to understand that it will require more work than running tests-passed, like running a staging server to test upgrades before you run them on production.

2 Likes

I just want something which is stable and reliable, and based on

tests-passed is what discourse.org deploys on their servers and it is better tested and more reliable than stable

I’ll be sticking to this. Two things are still very strange:

  • Why is this called test-passed and not stable then, if it’s indeed stable. “stable” could be renamed to “legacy” of some sorts.
  • The release system still doesn’t make sense. If we are building from a Git branch, what’s the whole point of doing releases at all? I’d love to be able to stick to 2.3.x until 2.4.x matures for example, and I believe with Discourse’s model this is not possible at all.

With all due respect but I disagree with this. Stable is very reliable and, well, stable. Rubygems updated a dependency which caused both tests-passed and stable to break and solving this was just a matter of backporting a fix.

BTW this could have been avoided by pinning rubygems to a specific version in the gem update command. gem update --system 3.0.6 would have been safe.

The fact that stable was longer broken than tests-passed is just a coincidence and - as far as I can remember - a first.

We’ve been doing this (sticking to stable as a default) for over six years with many hundreds of Discourse instances without significant issues.

4 Likes

Just in this thread there are multiple occasions when stable left rebuild in a broken state, it’s definitely not a first. If discourse.org commercial instances are on test-passed then I’ll be sticking to that.

We’ve been doing this (sticking to stable as a default) for over six years with many hundreds of Discourse instances without significant issues.

Sticking to stable and sticking to 2.3.x are very different things. For example stable doesn’t allow you to stay on 2.3.x until 2.4.x matures enough. For example with all things in production, I prefer to upgrade not until x.x.3 or x.x.4 comes out. This is not possible today I believe.

I know that’s true, but you’re not the average discourse admin. :wink: You’ve saved me a bunch of times and as a rule I read everything you say twice to make sure I’m remember it, but I still think that for most normal people it’s safest to stick with tests-passed.

You can use a git commit id rather than a tag.

But even if I do, it won’t save me in situation where stable is broken, will it? In both cases the problem was a missing backport, and that’d equally be missing in any git commit id, I believe.

Hence there is no such thing as a Discourse “release” where you download a zip file a-la-Wordpress or use a package manager like yarn/pip/gem simply because the Discourse is not released, but is “rebuilt”, always using live versions of external packages.

1 Like