Redis Server Failed To Start Advanced Key-Value Store

Hi, Hestia community
I want to ask whether is there any solution to run Redis with HestiaCP. I follow up on all methods on the Internet but I can still not enable Redis on my server
My OS: Debian 11
My PHP: 7.4.28

Methods that I have tried:

  • Set permission 755 for /etc/redis/redis.conf & /var/log/redis
  • Set owner redis:redis for /etc/redis/redis.conf & /var/log/redis
  • Change value from “supervised no” to “supervised systemd” of redis.conf file

Any experts, can you please give me any another solution to fix it :frowning:

Thanks & Have a nice working day !

Did you’ve installed the php7.4-redis module?

Hi @ScIT,
Actually, not yet bro
I thought that we have to enable Redis before installing php7.4-redis @@

Then install that first …

Hi @eris
I tried to install php7.4-redis but it does not change
When I run “systemctl status redis-server” command, it prints

redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-04-20 06:08:02 EDT; 25s ago
   Main PID: 12269 (code=exited, status=1/FAILURE)
        CPU: 10ms

Apr 20 06:08:02 sudoro systemd[1]: redis-server.service: Scheduled restart job, restart counter is >Apr 20 06:08:02 sudoro systemd[1]: Stopped Advanced key-value store.
Apr 20 06:08:02 sudoro systemd[1]: redis-server.service: Start request repeated too quickly.
Apr 20 06:08:02 sudoro systemd[1]: redis-server.service: Failed with result 'exit-code'.
Apr 20 06:08:02 sudoro systemd[1]: Failed to start Advanced key-value store.

and the redis error log shows:

9287:C 20 Apr 2022 05:46:58.837 # WARNING supervised by systemd - you MUST set appropriate values for TimeoutStartSec and TimeoutStopSec in your service unit.
9287:C 20 Apr 2022 05:46:58.838 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
9287:C 20 Apr 2022 05:46:58.838 # Redis version=6.0.16, bits=64, commit=00000000, modified=0, pid=9287, just started
9287:C 20 Apr 2022 05:46:58.838 # Configuration loaded
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 6.0.16 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 9287
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    | 
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'

9287:M 20 Apr 2022 05:46:58.839 # Server initialized
9287:M 20 Apr 2022 05:46:58.839 # 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.
9287:M 20 Apr 2022 05:46:58.839 # 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 madvise > /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 (set to 'madvise' or 'never').
9287:M 20 Apr 2022 05:46:58.840 * Ready to accept connections
9287:signal-handler (1650448401) Received SIGTERM scheduling shutdown...
9287:M 20 Apr 2022 05:53:21.534 # User requested shutdown...
9287:M 20 Apr 2022 05:53:21.534 * Saving the final RDB snapshot before exiting.
9287:M 20 Apr 2022 05:53:21.537 * DB saved on disk
9287:M 20 Apr 2022 05:53:21.537 * Removing the pid file.
9287:M 20 Apr 2022 05:53:21.537 # Redis is now ready to exit, bye bye...

For support regarding Redis contact the developers

Redis runs fine on our HestiaCP machine with Debian 11 and PHP 7.4.

We simply installed the Redis package, rebooted the server, Redis starts and runs. Nothing to edit in permissions etc. We’ve been using it with our Magento install with no issues.

1 Like

can confirm running Redis in parallel should not be an issue, there is nothing conflicting in HestiaCP.
if it does not run, that’s rather related to the specific system or custom settings.

maybe simply apt purge it and reinstall? make sure the purge doesn’t have leftovers anyway…

Hi @falzo,
I try on fresh install after finishing the HestiaCP install process but it’s still failed :frowning:

Only Memcached works for me :smiling_face_with_tear:

the error message seems to be a quite common one and people indeed recommend looking into permissions. to check that you probably want to also check under which user redis tries to run (is it really redis?)

a few more things that come to mind:

does /var/log/redis hold any more info to what you already posted?
what port it is configured to run on? can you make sure, that nothing else is running on that port?
has you machine IPv6 enabled/configured/disabled? …maybe redis tries to bind to local IPv6 but fails?

lastly, how large is your machine/do you have enough free memory and if it’s a virtual machine, what kind of virtualization do you use (kvm/lxc/ovz)?
do you use some template from a provider of yours or is deb 11 installed from an official ISO?

PS: of course you could install redis-server even before installing hestia - just if you would want to try and set up everything from scratch and make sure it does not depend on any components hestia installs.

Hi @Falzo,
My VPS is KVM-based
It runs on Minimal Debian 11 Bullseye (v11.3) template
Their spec is very excessive (5 Cores 3.5GHz+ / 10GB RAM / 100GB Storage)
This is the first time I try to install redis-server by myself. I have tried it 3-4 times with many solutions from the Internet but it’s still failed :frowning:

this seems odd. it should work out of the box if you install it via apt, there is not much to it.
I am not aware of any news or specifics with redis under debian 11, but haven’t run that combination myself so far. yet, as said, it should not be related to HestiaCP at all… just tried on a system running ub20, hestia, docker, xrdp and some more things in parallel just fine - and redis started immediately after the install.

maybe (if possible) try to use a different template from your provider (deb10/ub20) or reinstall using an ISO image and check if an apt install redis does it’s job there…

1 Like

Hi @falzo,
I have tried to install redis-server first and find everything is OK.
After that, I tried to install HestiaCP and all things are working fine.
I don’t know why it happens like that
Do you think it’s caused by UFW / IP Tables / Fail2Ban ?

hmm, weird. I have no answer to that… as written above I picked a random server of mine where I knew it wasn’t installed and tried and it did work out of the box.

did you reinstall your VM before your last try? maybe there really was something of with the providers install before… my best guess as already said would be something off with the network config, so that your redis-server could not bind to a port or interfaces correctly may it be IPv4 or IPv6.

happy for you if it works now ^^

1 Like

Hi @falzo,
Sorry for my late reply.

I finally find the solution for installing Redis (after installing HestiaCP)
After 6 times install & remove redis-server to find the solution, I realize that we only need to change 1 line inside /etc/redis/redis.conf

bind ::1



Then everything will work correctly without any issue (don’t need to change anything more) :smiley:

Thank you so much for your support!
Have a nice day.

glad you solved it and thanks for reporting back.

just to clarify, ::1 in that context tells redis to try and bind to IPv6 locally. so, as I wrote before it seems your server has IPv6 disabled or wrong configured.
this caused to redis fail on trying to bind to that, it could be more clear about that within the logs though…

yet, nothing related to Hestia itself :wink: :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.