Job for redis-server.service failed because the control process exited with error code

Check that supervised in /etc/redis/redis.conf matches the unit. If the unit is Type=notify, the config must say supervised systemd. A mismatch makes systemd wait for a readiness signal that never arrives, then kill a Redis that was running perfectly well.

grep -E '^(supervised|daemonize)' /etc/redis/redis.conf
systemctl show redis-server -p Type

This is the failure that wastes the most time, because Redis itself is fine. Start it by hand and it works; start it through systemd and it dies after the timeout. The two must agree.

The supervised and daemonize rules

1. Type=notify in the unit requires supervised systemd in the config. Without it, systemd waits for a notification Redis never sends, reports a timeout and kills the process.
2. daemonize yes with Type=notify or Type=simple is always wrong. Redis forks into the background, systemd loses track of the process it started, and treats the exit of the parent as a failure. Under systemd, daemonize should be no.
3. The Debian and Ubuntu packages already set this correctly. If you are hitting it, the config was almost certainly edited by a tutorial that assumed a manual build. Guides written for a source install routinely tell you to set daemonize yes, which breaks the packaged unit.

The other causes worth checking

1. Cannot open the log file. The journal shows Can't open the log file: Permission denied. Redis runs as the redis user and needs ownership of its log and working directories:

   sudo chown -R redis:redis /var/log/redis /var/lib/redis
   sudo chmod 750 /var/lib/redis

2. status=226/NAMESPACE. This is a sandboxing failure, not a Redis problem. The packaged unit sets ProtectHome, ReadOnlyPaths and PrivateTmp, and pointing dir or logfile at a path outside what the unit permits fails before Redis runs at all. Either move the path back under /var/lib/redis, or add a drop-in granting access with ReadWritePaths=. Inspect the effective unit with systemctl cat redis-server.
3. The bind address does not exist on the host. Redis exits if it cannot bind every address listed. A bind line copied from another machine naming an IP this host does not have fails immediately. The journal names the address.
4. A corrupt or unreadable dump.rdb or appendonly file. Redis refuses to start rather than serve partial data. The journal says so explicitly. Check ownership first, since this is usually a permissions problem rather than real corruption. Move the file aside only when you are willing to lose its contents.
5. Port 6379 already bound. Usually a second Redis instance or a stale process:

   sudo ss -tlnp | grep ':6379 '

What is not the cause

Two Redis log lines look alarming and are routinely blamed for startup failures they did not cause. The memory overcommit warning (Memory overcommit must be enabled) and the THP warning are both advisory. Redis logs them and keeps running. They are worth fixing for production stability, but if your service will not start, the cause is further down the log. Do not stop reading at the first scary line.

Likewise a WARNING: The TCP backlog setting of 511 cannot be enforced line is informational. Keep looking for an error that actually precedes the exit.

Reading the exit code

status=1/FAILURE means Redis started and rejected something, so read the journal. status=226/NAMESPACE means the unit’s sandboxing blocked a path, covered above. status=137 is SIGKILL, which for Redis is either the OOM killer or systemd timing out a Type=notify unit that never signalled readiness, which brings you back to the supervised setting at the top of this page. The full table is in the nginx version of this error.

How to stop it happening again

# prove the config parses before restarting anything
sudo -u redis redis-server /etc/redis/redis.conf --test-memory 0 2>&1 | head -5

Redis has no dedicated configuration test, so the practical substitute is starting it as the redis user in the foreground and watching the first few lines. That catches permissions, bad bind addresses and unreadable data files in one go. If those lines look clean, stop it and start the service normally.

Related

• Job for nginx.service failed: the same systemd error, plus the full exit-code table.
• Job for postgresql.service failed: another data service where permissions on the data directory are the usual cause.
• systemd service unit generator: build a unit with the right Type and sandboxing rather than copying one and hoping.