Ubuntu 20.04下Redis服务systemctl启动卡激活、反复重启问题

这个无限重启循环完全匹配Type=forking类型服务的判定异常特征，完整故障链路为：

• systemd采用Type=forking模式启动服务时，仅当指定PIDFile路径下的进程ID真实存在、且对应进程处于正常运行状态时，才会判定服务激活完成
• 如果在默认TimeoutStartSec（Ubuntu 20.04默认值为90s）超时前，systemd没能从指定路径读取到有效pid，就会认定服务启动失败，主动向整个服务cgroup发送SIGTERM信号终止所有关联进程
• 由于配置了Restart=always规则，进程被终止后systemd会立刻重新拉起启动流程，最终形成“Redis实际已正常运行→被systemd误判失败杀掉→反复重启”的死循环

• 核对Redis与systemd配置的pid路径一致性
  打开/etc/redis/redis.conf文件，定位pidfile配置项，确认其指向路径和systemd配置中声明的/var/run/redis/redis-server.pid完全匹配。这类故障最常见的诱因就是两边路径不统一：比如Redis配置写的是/var/run/redis.pid（不带redis子目录），和systemd的路径存在偏差，导致systemd永远找不到有效pid文件，卡在激活阶段。
• 校验运行时目录的权限匹配
  配置中声明的RuntimeDirectory=redis规则，会让systemd在服务启动时自动在/run目录下创建归属redis用户、权限为2755的redis子目录。如果之前手动以其他身份启动过Redis，残留了属主、权限不对的旧目录，会导致Redis无法在目标路径写入pid文件，触发判定异常。
• 确认AppArmor规则未拦截pid文件读写
  Ubuntu 20.04默认启用AppArmor强制访问控制，针对redis服务的规则如果拦截了进程对/var/run/redis目录的写入、以及systemd对pid文件的读取操作，同样会导致激活判定失败。

• 统一两端pid路径：将/etc/redis/redis.conf中的pidfile值修改为与systemd配置一致的/var/run/redis/redis-server.pid
• 清理异常残留目录：删除旧的/run/redis目录，重启服务时由systemd自动按配置创建合规的权限目录
• 执行systemctl daemon-reload重载systemd服务配置，再启动redis服务即可恢复正常

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