This article documents a solution to an issue we've witnessed on a cPanel server that had been configured with Redis and Redis PHP cache.

Server Environment

• Managed VPS Server with cPanel/WHM
• OS: CentOS v7.9.2009 STANDARD standard
• cPanel version: 110.0.17
• Apache-based server with PHP 7.2-8.1, Ruby 2.7, Nodejs 16, Redis, Redis PHP Cache

The Issue

Initially, the issue was reported as an issue with a WordPress installation on the server, where the client was complaining of "very slow site performance". When we investigated, we discovered a very large error log file that had only just been created in last 24 hours but was already ballooning beyond 2 MB of size. Naturally, that's where we started looking to determine what our client was experiencing and how we could resolve it.

Fortunately, for us, the errors logged in the WP site's error log were largely the same line, printed in rapid succession, one after the other (as evidenced by the preceding timestamps that indicated these errors were being logged more than 100x per second). 

Here's the error:

[07-Jan-2024 21:04:10 UTC] Redis server went away
[07-Jan-2024 21:04:10 UTC] Redis server went away
[07-Jan-2024 21:04:10 UTC] Redis server went away
[07-Jan-2024 21:04:10 UTC] Redis server went away
[07-Jan-2024 21:04:10 UTC] Redis server went away
[07-Jan-2024 21:04:12 UTC] Redis server went away

Except the error log file continued for nealry 150000 lines...

That was a major issue as this particular website was heavily dependent upon Redis caching, which we'd just learned "went away". When we asked systemd for more information regarding the status of Redis, we were given the following: (albeit, slightly modified to escape identifying information)

Starting Redis persistent key-value database...
 redis-server[19791]: *** FATAL CONFIG FILE ERROR (Redis 7.2.3) ***
 redis-server[19791]: Can't open the log file: Permission denied
 systemd[1]: redis.service: main process exited, code=exited, status=1/FAILURE
 systemd[1]: Failed to start Redis persistent key-value database.
 systemd[1]: Unit redis.service entered failed state.
 systemd[1]: redis.service failed.

So, now we see: "Can't open the log file: Permission denied", which indicates the underlying issue that was causing the WP performance issues as reported by our client. In this case, not only was the Redis not providing the caching service, but also, it was actively tying up all of the server's PHP workers to log the errors. Yikes!

The Solution

Ultimately, we were able to solve this chaos by untangling the permissions errors:

chown -R redis:redis /var/log/redis
chmod -R u+rwX,g+rwX,u+rx /var/log/redis
chmod +r /etc/redis/redis.conf

It should also be noted that another permissions change was also implemented to ensure these conditions would not be replicated again on the same server! :)