Switching from Beta to Stable version fails to bootstrap

(Toby Nieboer) #1

Continuing the discussion from Discourse 1.3 released!:

Followed this exactly and ./launcher rebuild app results in a failure to bootstrap.

[code]Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2015-06-25T21:56:33.967438 #41] INFO – :
== Seed from /var/www/discourse/db/fixtures/001_categories.rb

I, [2015-06-25T21:56:33.969465 #41] INFO – : Terminating async processes
I, [2015-06-25T21:56:33.969761 #41] INFO – : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/9.3/bin/postmaster -D /etc/postgresql/9.3/main pid: 70
2015-06-25 21:56:33 UTC [70-2] LOG: received fast shutdown request
2015-06-25 21:56:33 UTC [70-3] LOG: aborting any active transactions
2015-06-25 21:56:33 UTC [77-2] LOG: autovacuum launcher shutting down
2015-06-25 21:56:33 UTC [74-1] LOG: shutting down
I, [2015-06-25T21:56:33.976112 #41] INFO – : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 193
193:signal-handler (1435269393) Received SIGTERM scheduling shutdown…
2015-06-25 21:56:33 UTC [74-2] LOG: database system is shut down
193:M 25 Jun 21:56:34.058 # User requested shutdown…
193:M 25 Jun 21:56:34.059 * Saving the final RDB snapshot before exiting.
193:M 25 Jun 21:56:34.092 * DB saved on disk
193:M 25 Jun 21:56:34.093 # Redis is now ready to exit, bye bye…


RuntimeError: cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ failed with return #<Process::Status: pid 397 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:105:in `spawn’
exec failed with the params {“cd”=>"$home", “hook”=>“bundle_exec”, “cmd”=>[“su discourse -c ‘bundle install --deployment --verbose --without test --without development’”, “su discourse -c ‘bundle exec rake db:migrate’”, “su discourse -c ‘bundle exec rake assets:precompile’”]}
Commenting out the version again results in a normal rebuild. Is this potentially being caused by being on a higher version than the current stable release?

(Sam Saffron) #2

Missing more data from the logs … but …

We are not going to support going backward in versions. If you are on “latest” you need to wait for a new beta to move to it.

If you are on beta you need to wait for a new stable to move to it.

(Toby Nieboer) #4

Yeah, I don’t want to actually go back a version though - just switch update channels so that the next update I get is a stable version.

If there’s not a way to do this, then is the only option to wait until the stable channel catches up to where tests-passed was at the time I installed?

Is there a reason the default installation is tests-passed, btw? I’m surprised this question doesn’t come up more often. Unless you edit app.yml during the initial install (not mentioned in the guide) then you’re out of luck it seems.

(Kane York) #5

I don’t really see it as a huge problem because right now the stable branch is stable in edifice, not in bugs. Meta is continuously deployed, so if anything is totally broken, it gets fixed quickly. There aren’t any commits that get held back from the stable branch, like you see in projects like Chromium. There’s no feature flags that depend on your channel.

If you have a backup from before the stable version bump, or a brand-new site, you can wipe the database - rm -rf shared/standalone/postgres* .