Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Redis does not startup after a reboot

I have installed dataplicity and I also installed the ufw firewall. I wasn’t able to log in after installing the firewall so I uninstalled it - since my emonpi is on my home network behind a router. However now after a reboot I cannot log into emoncms and I get this error: Can’t connect to redis at localhost:6379 , it may be that redis-server is not installed or started see readme for redis installation

It seems as though the web server isn’t restarting? Anyway to fix this?

Thanks in advance.

If I type redis-server /var/www/emoncms it starts, but I get these messages:

[2153] 09 Jul 03:13:28.971 # Warning: 32 bit instance detected but no memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now.
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 2.8.17 (00000000/0) 32 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in stand alone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 2153
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

[2153] 09 Jul 03:13:28.975 # Server started, Redis version 2.8.17
[2153] 09 Jul 03:13:28.976 # 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.
[2153] 09 Jul 03:13:29.008 * DB loaded from disk: 0.032 seconds
[2153] 09 Jul 03:13:29.008 * The server is now ready to accept connections on port 6379

Alright, so I think that I may have figured something out. It looks like this could be a bug with the latest version . When I restored the whole thing to the Oct2017 release, it worked great, then after the 10 minutes of updating, it restarted and this same error showed up when trying to access:

Can’t connect to redis at localhost:6379 , it may be that redis-server is not installed or started see readme for redis installation

So then I type in redis-server into the SSH connection and it works normally. So after spending all night and a few hours today restoring everything, I am finally back up and running.

Hopefully this gets resolved in the next software update.

I’ve noticed my redis-server service no longer starts after a reboot either.
sudo systemctl status redis-server shows it as exited and sudo systemctl start redis-server starts it but it immediately exits.

Running sudo systemctl restart redis-server however, works for me. :roll_eyes:

+1. I just ran an emonBase Update yesterday (10 July 2018) and when I rebooted today I had to restart redis manually.

noted, I will see if I can replicate and fix this tomorrow.

@TrystanLea - I just ran the emonpi Update and I get the same error.

 

@Greebo fix worked great!

I think redis was trying to start before an IP address was available. I was able to resolve the issue by adding a longer delay before trying to start redis during startup.

rpi-rw
sudo nano /etc/rc.local

Then change “sleep 3” to “sleep 10”.

 # Start / Restart services,they should run happy now log dir's are created
  sleep 10
2 Likes

This really shouldn’t happen as there is (should be) an entry in the /lib/systemd/system/redis-server.service file requiring network to be running. If this was an issue, I’d have expected the wider community to have squealed.

After=network.target

Looks like the Redis service file has changed @TrystanLea and that could be the issue. Below my file for Redis-server V3.2.6 installed on a DietPi OS. Quite different to the service file on an old system running redis-server V2.8.17.

When we looked into the MQTT service, I wrote a longer bit on my research into systemd service startup here (I am no expert), which may provide a solution for a replacement file for the EmonPi if necessary.

Redis-server V3.2.6 service file

[Unit]
Description=Advanced key-value store
After=network.target
Documentation=http://redis.io/documentation, man:redis-server(1)

[Service]
Type=forking
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
PIDFile=/var/run/redis/redis-server.pid
TimeoutStopSec=0
Restart=always
User=redis
Group=redis
RunTimeDirectory=redis

ExecStartPre=-/bin/run-parts --verbose /etc/redis/redis-server.pre-up.d
ExecStartPost=-/bin/run-parts --verbose /etc/redis/redis-server.post-up.d
ExecStop=-/bin/run-parts --verbose /etc/redis/redis-server.pre-down.d
ExecStop=/bin/kill -s TERM $MAINPID
ExecStopPost=-/bin/run-parts --verbose /etc/redis/redis-server.post-down.d

UMask=007
PrivateTmp=yes
LimitNOFILE=65535
PrivateDevices=yes
ProtectHome=yes
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/redis
ReadWriteDirectories=-/var/log/redis
ReadWriteDirectories=-/var/run/redis
CapabilityBoundingSet=~CAP_SYS_PTRACE

# redis-server writes its own config file when in cluster mode so we allow
# writing there (NB. ProtectSystem=true over ProtectSystem=full)
ProtectSystem=true
ReadWriteDirectories=-/etc/redis

[Install]
WantedBy=multi-user.target
Alias=redis.service
1 Like

I had the same problem after burning the October 2017 image to a new SD card and running the update. Increasing sleep to 10, as suggested by @brandock, has fixed it.

Again I had the same problem after burning the October 2017 image to a new SD card and running the update. By the sleep interval from 3 to 10, as suggested by @brandock, fixed the issue.