记录redis翻车

因为不是运维，所以对于linux中的各种服务管理不熟悉，这是基础不牢固
已知有一个叫init的管理和一个systemd的服务管理
因为之前的几个服务器都是使用的init管理，但是redis比较旧，遂打算新开的服务器使用新版本redis，又因为对服务管理不熟悉，改用了systemd(已经忘记为什么当时选择用这个，也许是哪个优快云或者google的记录，哈哈哈),然后就开始翻车了，一直无法开机自启，只能手动启动。与google联调N久依然没找到问题，遂放弃。暂时使用手启。直到现在项目挂了，服务器重启后多个功能挂了，才重新开始维修。再次与gpt疯狂联调，开始查日志(以前也有查，当时没开始用gpt，对linux熟悉度不够)，修改文件权限，修改redis.service,查系统日志，查redis日志。一直维护N久，最终发现，gpt4也不过如此(歪嘴),切google，终于在stack overflow找到答案，原来是redis的后台配置与systemd的Type=“simple”冲突了，这是解决方法的连接，感谢大佬：

https://stackoverflow.com/questions/42079847/determining-why-redis-is-receiving-a-sigterm-every-minute-or-two

以下是愚蠢的gpt4的解释：

确实，你遇到的问题和 Type 指令以及 daemonize 设置的不兼容性有关。在 systemd 管理的服务中，Type=simple 是默认的服务类型，适用于直接由 systemd 启动并且不会自行作为后台进程运行的应用程序。当使用 daemonize yes 配置 Redis 时，Redis 将尝试自行后台运行，这与 systemd 的 Type=simple 期望的行为冲突，导致可能出现服务启动后立即停止的问题。

解决方案
要解决这个问题，你有以下两个选项：

更改 systemd 服务类型:
将 systemd 配置文件中的 Type 指令改为 forking。这是用于那些会自行产生一个子进程然后立即返回成功退出状态的服务。修改后，systemd 会等待原始进程退出但保持跟踪子进程，这对于需要后台运行的传统守护进程是必需的。

[Service]
Type=forking

禁用 Redis 的守护进程模式:
在 Redis 配置文件 (redis.conf) 中，将 daemonize 设置为 no。这意味着 Redis 将不会尝试自行后台运行，而是依赖于 systemd 来管理其进程。

daemonize no

推荐操作
对于大多数使用 systemd 管理服务的现代系统，推荐使用第二种方案，即在 redis.conf 中设置 daemonize no，并保持 systemd 服务文件中的 Type=simple（或省略该行，因为 simple 是默认值）。这样利用 systemd 的服务管理功能，可以更好地控制服务的启动、停止和重新启动，也可以更好地集成到系统的日志和监控工具中。

更新这些配置后，记得重新加载 systemd 配置并重启 Redis 服务：

sudo systemctl daemon-reload
sudo systemctl restart redis.service

检查服务状态确保一切正常：

bash
Copy code
sudo systemctl status redis.service
这些更改应该会解决你的问题，使 Redis 正常运行并被 systemd 正确管理。

收工