Skip to content

Instantly share code, notes, and snippets.

@webhouse-dev
Last active November 14, 2024 15:10
Show Gist options
  • Save webhouse-dev/eacabdaa74554cbe108043768d2c458e to your computer and use it in GitHub Desktop.
Save webhouse-dev/eacabdaa74554cbe108043768d2c458e to your computer and use it in GitHub Desktop.
Redis via Unix socket on CloudLinux with CageFS

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.

@VirtusB
Copy link

VirtusB commented Apr 13, 2022

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

Did you find out how to fix it?

@Fidelity88
Copy link

Fidelity88 commented Apr 13, 2022

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

@VirtusB
Copy link

VirtusB commented Apr 13, 2022

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

@Fidelity88
Copy link

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

@Fidelity88
Copy link

Fidelity88 commented Apr 11, 2023

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

@McSwizzlestix
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment