Ubuntu 16.04与CentOS 7下Redis Sentinel Systemd服务启动失败求助

Hey there, let's dig into why your Redis Sentinel won't start via systemd but runs fine manually. Since manual startup works, the issue almost always boils down to differences in environment context, incorrect systemd service configuration, or path mismatches. Here's a step-by-step breakdown to fix this:

1. Audit Your Systemd Service File #

First, locate your Redis Sentinel systemd unit file—usually at /etc/systemd/system/redis-sentinel.service or /usr/lib/systemd/system/redis-sentinel.service. Open it up and check these critical settings:

• WorkingDirectory: Make sure this points to the directory where your sentinel.conf lives (e.g., /var/lib/redis). Systemd runs services from a default working directory, so a missing or incorrect path here can cause it to fail finding your config.
• ExecStart: Verify the path to sentinel.conf is absolute, not relative. For example, use /usr/bin/redis-server /etc/redis/sentinel.conf --sentinel instead of redis-server sentinel.conf --sentinel—manual startup might work because you're in the config directory, but systemd isn't.
• User/Group: Confirm the service runs as the same Redis user you're using manually (e.g., User=redis). You mentioned 0600 permissions are set, but double-check the systemd user has access to both the config file and data directory.

To get detailed error logs (way more useful than the partial output you shared), run these commands:

# Check current service status
systemctl status redis-sentinel.service
# Pull full startup logs
journalctl -u redis-sentinel.service -xe

This will show you exactly why systemd is failing—like missing config files, permission denials (even if you think permissions are right), or invalid config syntax.

2. Validate Sentinel Configuration Path & Content #

Even if you've configured sentinel.conf on all nodes, ensure systemd is using the correct file (not a default, unmodified version). For example, if you edited /var/lib/redis/sentinel.conf but systemd is pointing to /etc/redis/sentinel.conf, it'll use the wrong settings.

Also, double-check these key configs in your sentinel.conf:

• dir /var/lib/redis: This directory must exist, and the Redis user needs write access here (Sentinel creates temp files and logs here).
• sentinel monitor mymaster 10.9.8.1 6379 2: Confirm the master IP/port is correct, and the quorum value makes sense for your 3-node setup.
• Since manual startup works, the config syntax is likely fine—but it never hurts to run a quick check with redis-check-sentinel /path/to/sentinel.conf.

3. Fix Environment Context & SELinux Issues #

Systemd runs services in a stripped-down environment, which can differ from your shell's context. For example, your PATH might include Redis's binary directory, but systemd's doesn't. Add this to your systemd service file if needed:

Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"

On CentOS 7, SELinux is often the culprit even with correct file permissions. Test this by temporarily disabling SELinux:

setenforce 0

If Sentinel starts after this, you'll need to fix the SELinux context permanently:

# Apply the correct SELinux context to Redis directories
chcon -R system_u:object_r:redis_var_lib_t:s0 /var/lib/redis
# Make the change persistent across reboots
semanage fcontext -a -t redis_var_lib_t "/var/lib/redis(/.*)?"
restorecon -R /var/lib/redis

4. Align Systemd Command with Manual Startup #

Compare the command you use manually with the ExecStart line in systemd. If you start it like this:

cd /var/lib/redis && redis-server sentinel.conf --sentinel

Then your systemd service should mirror this:

WorkingDirectory=/var/lib/redis
ExecStart=/usr/bin/redis-server sentinel.conf --sentinel

This ensures systemd runs the service in the same context as your manual startup.

5. Reload Systemd & Retest #

After making any changes to the systemd service file, reload the config and restart the service:

systemctl daemon-reload
systemctl restart redis-sentinel.service

Then check the status again with systemctl status redis-sentinel.service—if it's running, you're good to go. If not, the journalctl logs will point you to the remaining issue.

内容的提问来源于stack exchange，提问作者Joenarr Bronarsson