Redis Sentinel进程挂了由systemd兜底重启，因其默认可用、配置简洁、日志集成好；需配置Restart=always、明确--sentinel参数、检查端口绑定、配置语法及目录权限，并通过redis-cli验证哨兵实际工作状态。
Redis Sentinel进程挂了谁来管？Systemd是最省心的选择
Redis Sentinel本身不负责自重启，进程退出后不会自动拉起——这是设计使然，不是bug。必须靠外部进程管理器兜底，而systemd在现代Linux发行版中默认可用、配置简洁、日志集成好，比supervisord更轻量且无额外依赖。
常见错误现象：systemctl status redis-sentinel显示inactive (dead)，但ps aux | grep sentinel确实没进程；查/var/log/syslog或journalctl -u redis-sentinel发现报exit code=exited, status=1/FAILURE，但没进一步线索。
- 确保Sentinel配置文件路径正确，
systemd服务文件里ExecStart要明确指定--sentinel参数和配置路径，例如：/usr/bin/redis-server /etc/redis/sentinel.conf --sentinel - 必须设置
Restart=always（不能只用on-failure），因为Sentinel异常退出可能不走标准错误码路径 - 加上
RestartSec=5和StartLimitIntervalSec=0，避免频繁崩溃被systemd限流停机 - 用
Type=notify需Redis编译时带systemd支持，否则改用Type=simple更稳妥
Supervisor能用，但要注意它的信号传递盲区
supervisord可以拉起Sentinel，但它默认用SIGTERM停止进程，而Redis Sentinel对SIGTERM的响应是“优雅退出”，不写sentinel.conf状态变更；如果恰好在故障转移中途被杀，可能造成哨兵视图不一致。
使用场景：仅当系统无法使用systemd（如老旧CentOS 6）或已有supervisord统一纳管其他服务时才考虑。
-
command字段必须显式加--sentinel，例如：command=/usr/bin/redis-server /etc/redis/sentinel.conf --sentinel - 设
autorestart=true和startretries=3，但别设太高，避免掩盖配置错误 - 务必加
stopasgroup=true和killasgroup=true，否则子进程残留可能干扰下一次启动 -
stderr_logfile建议指向/var/log/redis/sentinel-error.log，别用syslog，否则日志时间戳易错乱
为什么Sentinel会自己退出？先盯住这三类日志
不是所有退出都该靠守护进程硬拉起——有些是配置或环境问题反复触发，拉起来又挂，形成“僵尸循环”。得先看日志定位根因。
典型错误信息：Failed to bind to address 0.0.0.0:26379: Address already in use、Invalid argument 'sentinel monitor' in sentinel.conf、Could not rename tmp config file。
- 检查
sentinel.conf里sentinel monitor行是否指向了已下线的master，或IP/DNS解析失败 - 确认
dir配置的目录存在且redis用户有读写权限，Sentinel需要在此生成临时配置文件 - 留意
protected-mode yes与bind配置冲突——若只绑127.0.0.1却开启保护模式，远程哨兵无法通信，可能引发选举失败后主动退出
守护进程拉起后，怎么确认它真在干活？
进程起来了不等于Sentinel正常工作。它得连上master、和其他哨兵握手、能响应SENTINEL masters命令才算数。
别只信ps或systemctl is-active，那只是操作系统层面的状态。
- 用
redis-cli -p 26379 ping验证端口通不通；返回PONG才说明监听正常 - 执行
redis-cli -p 26379 sentinel masters，至少看到一个master条目，且num-slaves、num-other-sentinels字段非零 - 查
redis-cli -p 26379 sentinel sentinels <master-name>，确认其他哨兵IP和端口列出来了——这是判断集群视图收敛的关键 - 如果
sentinel.conf被自动重写过，检查文件修改时间是否更新，以及sentinel known-replica等行是否动态追加
配置热加载、主从切换、哨兵间通信这些事，全靠Sentinel进程持续运行并维持内存状态。守护进程只解决“活下来”的问题，不解决“干得好”的问题——这点最容易被忽略。
