Redis RIP on new fresh common install

(Nick) #1

I tried to create new installation on new VPS, but get logs below in shared/standalone/log/rails/production.log (and probably this is why i cant send email trough smtp).
So, i checked same on DigitalOcean Ubuntu 16 droplet, same results.
Installation commands i use (like in discourse basic install):

wget -qO- | sh
mkdir /var/discourse
git clone /var/discourse
cd /var/discourse
Wait 5 seconds and setup create 2GB SWAP by himself
Set smtp credentials
Thats all

Logs from shared/standalone/log/rails/production.log:

Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack ["/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:345:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:331:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:101:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:293:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:100:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:364:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:221:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:306:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:220:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis/client.rb:120:in `call'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis.rb:862:in `block in get'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis.rb:58:in `block in synchronize'", "/usr/local/lib/ruby/2.4.0/monitor.rb:214:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis.rb:58:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/redis-3.3.5/lib/redis.rb:861:in `get'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.1.2/lib/message_bus/backends/redis.rb:284:in `process_global_backlog'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.1.2/lib/message_bus/backends/redis.rb:320:in `block in global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.1.2/lib/message_bus/backends/redis.rb:333:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.1.2/lib/message_bus.rb:525:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.1.2/lib/message_bus.rb:473:in `block in new_subscriber_thread'"]`

(Nick) #3

you are focusing on my email configuration, but forgot about error in logs

(Rafael dos Santos Silva) #4

Can you retry after downgrading Docker to 17.10?

(Nick) #5

Downgrade Docker to 17.09 on new machine, same errors

(Miro Michalicka) #6

I’m experiencing the same issue on Azure cloud with Ubuntu 16.04LTS. I tried the latest docker as well as downgrade to 17.10 as was suggested.

(Miro Michalicka) #7

This issue might be related to Ubuntu itself, everything is running perfect on 17.04

(Matt Palmer) #8

What do the Redis-related logs say? It’s presumably failing to start up.

(Nick) #9

You mean 16.04 i think, and - email sending working fine for example?

(Nick) #10
50:M 13 Jan 18:14:12.422 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
50:M 13 Jan 18:14:12.422 # Server started, Redis version 3.0.6
50:M 13 Jan 18:14:12.422 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
50:M 13 Jan 18:14:12.422 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
50:M 13 Jan 18:14:12.428 * DB loaded from disk: 0.006 seconds
50:M 13 Jan 18:14:12.428 * The server is now ready to accept connections on port 6379
50:M 13 Jan 18:19:13.039 * 10 changes in 300 seconds. Saving...
50:M 13 Jan 18:19:13.042 * Background saving started by pid 1103
1103:C 13 Jan 18:19:13.058 * DB saved on disk


46:M 14 Jan 06:30:50.121 * Background saving terminated with success
46:M 14 Jan 06:35:51.078 * 10 changes in 300 seconds. Saving...
46:M 14 Jan 06:35:51.079 * Background saving started by pid 10074
10074:C 14 Jan 06:35:51.092 * DB saved on disk
10074:C 14 Jan 06:35:51.093 * RDB: 0 MB of memory used by copy-on-write
46:M 14 Jan 06:35:51.179 * Background saving terminated with success
46:M 14 Jan 06:40:52.042 * 10 changes in 300 seconds. Saving...
46:M 14 Jan 06:40:52.042 * Background saving started by pid 10393
10393:C 14 Jan 06:40:52.056 * DB saved on disk
10393:C 14 Jan 06:40:52.057 * RDB: 0 MB of memory used by copy-on-write
46:M 14 Jan 06:40:52.142 * Background saving terminated with success

(Nick) #11

Can you try to rebuild app? And try send something after that? And look at logs please

(Nick) #12

Ok, so, email sending and this errors in log different things, you can get this errors in production.log after rebuild app and wait are while6 and than will be reproduced periodically.

(Matt Palmer) #13

So… Redis is running, but the app can’t connect? Are you running an all-in-one (standalone) setup with everything in one container, or split out somehow? Any non-default firewall/security things going on?

(Nick) #14

Looks like sometimes app cant connect, I write in first message in this tree whole bunch of commands, nothing else - fresh droplet from DO.


I have the same issue with AWS EC2 running 16.04LTS