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.

@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.