Upgrade from v2.0.0.beta10 +37 to 2.1.0.beta1 does fail

(Guido Drehsen) #1

I just tried on the console the upgrade from v2.0.0.beta10 +37 to the current 2.1.0.beta1 but it fails to upgrade:

Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 14438 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108: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'"]}
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

I scrolled further up and I do see quite some HTTP 429 errors, for example

HTTP GET https://index.rubygems.org/info/uglifier
HTTP GET https://index.rubygems.org/info/unf_ext
HTTP GET https://index.rubygems.org/info/unf
HTTP GET https://index.rubygems.org/info/unicorn
HTTP GET https://index.rubygems.org/info/webmock
HTTP GET https://index.rubygems.org/info/webpush
HTTP 200 OK https://index.rubygems.org/info/tilt
HTTP 200 OK https://index.rubygems.org/info/sprockets-rails
HTTP 429 Too Many Requests https://index.rubygems.org/info/r2
HTTP 200 OK https://index.rubygems.org/info/sshkey
HTTP 200 OK https://index.rubygems.org/info/unf_ext
HTTP 200 OK https://index.rubygems.org/info/unf
HTTP 200 OK https://index.rubygems.org/info/webmock
HTTP 200 OK https://index.rubygems.org/info/uglifier
HTTP 200 OK https://index.rubygems.org/info/unicorn
HTTP 429 Too Many Requests https://index.rubygems.org/info/rails_multisite
HTTP 200 OK https://index.rubygems.org/info/progress
HTTP 429 Too Many Requests https://index.rubygems.org/info/rqrcode
HTTP 429 Too Many Requests https://index.rubygems.org/info/ruby-readability
HTTP 200 OK https://index.rubygems.org/info/image_size

but other then that I have not seen any other error at least not as far as I could scroll up.
I expect that one of the plugins is creating the problem even though we only have very few plugins installed:

    - exec:
        cd: $home/plugins
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-tagging
          - git clone https://github.com/angusmcleod/discourse-locations.git
          - git clone https://github.com/angusmcleod/discourse-events.git
#          - git clone https://github.com/angusmcleod/discourse-category-moderator-lite.git
#          - git clone https://github.com/angusmcleod/discourse-layouts.git
          - git clone https://github.com/cpradio/discourse-plugin-checklist.git
          - git clone https://github.com/discourse/discourse-chat-integration.git
          - git clone https://github.com/DemokratieInBewegung/dc-plugins-moderation-plusplus.git

I will try another rebuild again tomorrow without our own moderation++ plugin

On other thing I noticed. For whatever reason since a couple of month I do always have to install the new betas with the ssh console. In the admin screen it does always show me that a new beta is available like currently:

but when I clicked on the admin/upgrade I do always get:

You are running an old version of the Discourse image.

Upgrades via the web UI are disabled until you run the latest image.

To do so log in to your server using SSH and run:

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

More info on our support site

which I am therefore always doing but with the next beta I have to do it again.
How can I fix it that an upgrade with the web admin interface will be possible again?
I know that it worked a couple months ago with the web admin interface and only from time to time I had to use the ssh console for an upgrade, but at least the last ten upgrades or so I had to do with the ssh console.

(Mittineague) #2

Not that it is causing problems, but it might be and it is no longer needed, so you can comment out / remove that line

GitHub - discourse/discourse-tagging: Tagging functionality for Discourse Forums

No longer needed

Tagging was introduced into Core in April of 2016. If you are using Discourse 1.6.0.beta2 or later, you do not need this plugin.

See this post for more information.

(Jay Pfaffman) #3

The problem appears to be with rubygems and rate limiting. This was a problem about a year ago and it went away (and a month ago I got an email from them asking if I needed help).

You might just try again.

(Guido Drehsen) #4

well I tried it again a couple of times. This time the HTTP GET for the rubygems.org files did all result in HTTP 200 OK

But the error remains the same, I am unable to upgrade to 2.1.0.beta1

I disabled the plugin mentioned above, I did also disable our own plugin.
But I do always end up with the same error. :frowning:

Bundle complete! 106 Gemfile dependencies, 184 gems now installed.
Gems in the group development were not installed.
Bundled gems are installed into `./vendor/bundle`

I, [2018-06-08T04:14:56.947909 #13]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
Discourse requires Ruby 2.4.0 or up
I, [2018-06-08T04:14:57.431418 #13]  INFO -- :
I, [2018-06-08T04:14:57.432280 #13]  INFO -- : Terminating async processes
I, [2018-06-08T04:14:57.432615 #13]  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.5/bin/postmaster -D /etc/postgresql/9.5/main pid: 42
I, [2018-06-08T04:14:57.432967 #13]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 155
2018-06-08 04:14:57.433 UTC [42] LOG:  received fast shutdown request
2018-06-08 04:14:57.433 UTC [42] LOG:  aborting any active transactions
2018-06-08 04:14:57.434 UTC [49] LOG:  autovacuum launcher shutting down
155:signal-handler (1528431297) Received SIGTERM scheduling shutdown...
2018-06-08 04:14:57.436 UTC [46] LOG:  shutting down
2018-06-08 04:14:57.439 UTC [46] LOG:  database system is shut down
155:M 08 Jun 04:14:57.509 # User requested shutdown...
155:M 08 Jun 04:14:57.509 * Saving the final RDB snapshot before exiting.
155:M 08 Jun 04:14:58.224 * DB saved on disk
155:M 08 Jun 04:14:58.224 # Redis is now ready to exit, bye bye...

Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 18019 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108: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'"]}
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

(Kane York) #5

there’s your error - you are running in Docker, right?

(Guido Drehsen) #6

One additional thing, I read in some of the beta release notes of 2.0 (I think it was beta 6 or 7) that it will automatically upgrade to postgres 10.
But even though I always had installed every new beta I just noticed that our installation it is still on postgres 9.5 (psql (PostgreSQL) 9.5.12)
I assume I will have to follow the instructions mentioned in the template of this post to get it on 10, right?

I also tracked the complete output in my last try into a file in order to check the output.
I do see that the rebuild starts with a fatal:

root@marktplatz:/var/discourse# ./launcher rebuild app
fatal: ref HEAD is not a symbolic ref
Stopping old container
+ /usr/bin/docker stop -t 10 app
cd /pups && git pull && /pups/bin/pups --stdin
Already up-to-date.

I remember that I have seen the fatal already for quite some time but it still did upgrade the betas.
I do see in the /var/discourse/.git directory a file called HEAD from last year
-rw-r–r-- 1 root root 41 Oct 18 2017 HEAD

What will I have to do to remove the fatal at the beginning?

(Guido Drehsen) #7

yes we are running Discourse in docker (not docker-compose) since it is the only container on that server.

root@marktplatz-app:/var/www/discourse# ruby -v
ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]

should not the whole image be upgraded automatically with “git pull” and “./launcher rebuild app”?

looks like I still have an old image which would also explain that the upgrades can no longer be done with the web interface …

(Guido Drehsen) #8

I solved the problem, we are now on postgres 10, on ruby 2.4.4p296 and on the latest beta v2.1.0.beta1 +149

thanks everyone for pointing me to the right direction especially with the ruby hint :wink:
Topic can be closed now.

(Jeff Atwood) #11