Redis via Unix socket on CloudLinux with CageFS

Cloudlinux Redix via Unix socket.md

It's not a secret that Redis service is a really great backend caching service. Normally people use that via TCP. It's fast and reliable. However if you do benchmark via unixsocket you will see that it will double amount of requests per second (of course depend on your server but much much faster than TCP). Redis via unixsocket is the best setup to go... however people using CageFS in Cloudlinux will struggle with permissions and they won't be able to connect to unixsocket. Here is the solution!

Step 1: change redis config to use unixsocket (still keeping TCP). In /etc/redis.conf uncomment and change lines:

# Unix socket.
#
# Specify the path for the Unix socket that will be used to listen for
# incoming connections. There is no default, so Redis will not listen
# on a unix socket when not specified.
#
unixsocket /var/run/redis/redis.sock
unixsocketperm 755

Step 2: restart redis service

systemctl restart redis

Step 3: add the path to redis.sock in the CageFS configuration:

cat /etc/cagefs/cagefs.mp
# Lines, which start with "/", specify mounts, that are common for all users:
/var/run/redis

Step 4: update CageFS

cagefsctl --force-update && cagefsctl -M
Updating users ...
Updating statuses of users ...

Enjoy Redis via unixsocket. If you configure it on your WordPress via LSCache plugin in Cache > Object pick Redis. Host will be a path to redis.sock ( /var/run/redis/redis.sock ). Port set to 0.

Hmm I tried your instructions, but somehow (on Litespeed webserver) I get a 'permission denied'. Even though I get a 'PONG' result when running either this as root:
redis-cli -s /var/run/redis/redis.sock

or as a user:
cagefsctl -e usernamehere && redis-cli -s /var/run/redis/redis.sock

Maybe you know the solution? Thanks!

@Fidelity88 I seem to have the same issue, although it isn't a Litespeed webserver.

Did you find out how to fix it?

@Fidelity88
Did you find out how to fix it?

Nope! I'm simply not running it on Unix socket. Less performance, but still works. If you ever find the solution, let me know!

@webhouse-dev ^

@Fidelity88

I fixed it - at least for my server with CloudLinux, Apache and Engintron plugin (nginx)

You need to add the user to the "redis" group with "usermod -a -G redis username_here"

And instead of "unixsocketperm 755" it needs to be "unixsocketperm 770"
Remember to run "cagefsctl --force-update && cagefsctl -M" and check that redis.sock can actually be seen by the user

You should also logout and login again after adding the user to the redis group.

And you need to restart PHP if you're using a service like PHP-FPM, CRIU etc....

@VirtusB Thank you so much!!! I will try soon.

@VirtusB Almost a year later haha! But I can confirm, this did indeed fix the issue! Thank you so much.

I still have one slight issue. After each server reboot, I still get the 'permission denied' notice when trying to connect from a regular website. Using CLI with redis-cli, everything works.

The solution for this is to simply run cagefsctl --force-update && cagefsctl -M one last time, and then everything works up until next reboot. Since this is a production server, this system normally never reboots so until I find a solution, unix works now. Thanks again!

@Fidelity88
The solution for this is to simply run cagefsctl --force-update && cagefsctl -M one last time, and then everything works up until next reboot. Since this is a production server, this system normally never reboots so until I find a solution, unix works now. Thanks again!

You could create a script containing

#!/bin/bash
cagefsctl --force-update && cagefsctl -M

then from root shell type crontab -e and add @reboot /usr/bin/php /path_to_script/your-script.sh to your crontab or something like that. I haven't added a cron to run script at reboot in a while. Someone else may be able to correct/confirm.

You may have to add more to get the timing correct and not mess up your boot sequence.