• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Changes to use Redis 6.0 in Plesk

Zoo3

Regular Pleskian
Redis 6.0 has been released. I simply updated it with yum and Redis stopped working. Redis 6.0 adds new features such as TLC/SSL and ACL. It's probably a configuration issue with this.
How should I install redis 6.0 in the environment where Plesk is used?
 
I can't start redis when I update to Redis 6.0.
What do you mean exactly "stopped working"?
Have you considered this solution Instruction - How to install latest Redis server ?
I can't start redis when I update to Redis 6.0.

I looked at the site that you presented to me. My current Redis is 5.0.9. wget and tcl components are up to date.
I've already set up transparent_hugepage and vm.overcommit_memory as well.

Redis.conf, which the official site presents as a reference, has newly added SSL/TLC and ACL items. Of course I've updated it, so redis.conf is the same as it used to be. I made a fix with the existing configuration based on redis 6.0's redis.conf. I haven't figured out that SSL/TCL or ACL part yet, so I've commented it all out there. Even so, I still can't start Redis.
 
I seem to be able to start Redis-server if I do it manually.
Code:
sudo -u redis sh -c "/usr/bin/redis-server /etc/redis/6379.conf"

In other words, I thought there was something wrong with Systemd's description.
I remove the "Type" and the startup itself succeeds, but I can't use the redis. It's the same when I change Type to SIMPLE, FORKING, etc.

Code:
[Unit]
Description=Redis
After=network.target rc-local.service

[Service]
Type=notify
ExecStart=/usr/bin/redis-server /etc/redis/6379.conf
ExecStop=/usr/bin/redis-cli -a PASSWORD shutdown
User=redis
Group=redis

[Install]
WantedBy=multi-user.target

Code:
Got notification message from PID XXXX, but reception only permitted for main PID which is currently not known
> ExecStart=/usr/bin/redis-server /etc/redis/6379.conf
I added "--supervised systemd" to the ExecStart above and it won't start.

Is there a way to write systemd that is unique to Redis 6.0?
 
Similar to me on Ubuntu 18.04. I also used 5.0.x to 5.0.9 successfully since years. But with 6.0.1 it's totaly different. My Redis seems to work, but the point in status is grey, not green. By installing there came NO config file, NO working directory, NO rdb and aof file, NO error log are created- it seems running without the most impoortant stuff.
Totally crazy. I can't configure it. But in my community (WoltLab) in Cache is shown Redis 6.0.1 and files are cached.
It's ghost-like. Never ever seen something like that. But I'll wait not long. If I can't get information I will return to 5.0.9 where I can watch logs, see the files and where I can configure it over config file in etc/redis/6379.conf or (like now trying redis.conf).

Code:
systemctl status systemd-redis_server
● (<<< grey) systemd-redis_server.service - Redis data structure server
   Loaded: loaded (/etc/systemd/system/systemd-redis_server.service; enabled; vendor preset: enabled)
   Active: activating (start) since Tue 2020-05-05 00:17:00 CEST; 20h ago
     Docs: https://redis.io/documentation
Main PID: 31270 (redis-server)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/systemd-redis_server.service
           └─31270 /usr/local/bin/redis-server *:6379

May 05 00:17:00 server.x.com systemd[1]: Starting Redis data structure server...
May 05 00:17:00 server.x.com redis-server[31270]: 31270:C 05 May 2020 00:17:00.131 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
May 05 00:17:00 server.x.com redis-server[31270]: 31270:C 05 May 2020 00:17:00.131 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=31270, just starte
May 05 00:17:00 server.x.com redis-server[31270]: 31270:C 05 May 2020 00:17:00.131 # Configuration loaded
May 05 00:17:00 server.x.com redis-server[31270]: 31270:C 05 May 2020 00:17:00.131 # WARNING supervised by systemd - you MUST set appropriate values for TimeoutStartS
May 05 00:17:00 server.x.com redis-server[31270]: 31270:M 05 May 2020 00:17:00.132 * Running mode=standalone, port=6379.
May 05 00:17:00 server.x.com redis-server[31270]: 31270:M 05 May 2020 00:17:00.132 # Server initialized
May 05 00:17:00 server.x.com redis-server[31270]: 31270:M 05 May 2020 00:17:00.179 * Ready to accept connections

Thanks @IgorG for fast and really good support by instructions. Perhaps there is a little more to do like running an installer script to create the necessary files and directories like in earlier versions/releases.
Port : 6379
Config file : /etc/redis/6379.conf ??? not existing
Log file : /var/log/redis_6379.log ??? not existing
Data dir : /var/lib/redis/6379 ??? not existing
Executable : /usr/local/bin/redis-server <<<< was done by enabling redis 6.0.1
Cli Executable : /usr/local/bin/redis-cli <<<< was done by enabling redis 6.0.1
 
Last edited:
> daemonize yes
I've been setting DAEMONIZE to YES. If I set "daemonize no" in redis.conf, I was able to service it in systemd and start it. When I set it to "daemonize yes", I couldn't start no matter which one I set to "supervised XX". XX: no, upstart ,systemd, auto.

Did redis 6.0 change the way it was daemonized?
 
Strange...

I had the same problem. Changed to daemonize yes, daemon-reload, tried to start the service (not successful), changed back to daemonize no, tried to start the service and... IT WORKED...now the service is officially "started" and not "activating" any more. Works after reboot as well...

Redis 6.0.5 on CentOS 8.2 btw...

Strange...
 
Back
Top