redis.service配制redis启动失败原因

centos7下编译安装redis,使用/data/redis/bin/redis-server /data/redis/6379.conf启动正常,用systemctl启动失败,下面总结下解决过程

redis.service配制文件如下:

image.png

用systemctl启动失败的具体原因,还不得而知。将redis.conf中daemonize yes 改回no时,systemctl方式启动redis正常, 网上翻看资料时有文章说是daemonize设置成yes影响systemctl启动redis,个人觉得并非是daemonize设置成yes的问题。

要解决这一问题,总要翻看更多相关资料。无意中看到一篇“systemctl介绍”的文章,仔细看服务类型一节:

服务类型

编写自定义的 service 文件时,type可以选择几种不同的服务启动方式。启动方式可通过配置文件 [Service] 段中的 Type= 参数进行设置。

  • Type=simple(默认值):systemd认为该服务将立即启动。服务进程不会fork。如果该服务要启动其他服务,不要使用此类型启动,除非该服务是socket激活型。

  • Type=forking:systemd认为当该服务进程fork,且父进程退出后服务启动成功。对于常规的守护进程(daemon),除非你确定此启动方式无法满足需求,使用此类型启动即可。使用此启动类型应同时指定 PIDFile=,以便systemd能够跟踪服务的主进程。

  • Type=oneshot:这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。

  • Type=notify:与 Type=simple 相同,但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。

  • Type=dbus:若以此方式启动,当指定的 BusName 出现在DBus系统总线上时,systemd认为服务就绪。

  • Type=idle: systemd会等待所有任务处理完成后,才开始执行idle类型的单元。其他行为和Type=simple 类似。

type的更多解释可以参考 systemd.service(5)


即然simple与notify差不多,那就改成notify吧。

redis.service编辑后别忘了执行 systemctl daemon-reload。

再编辑redis.conf文件中daemonize为yes

systemctl start redis.service

启动成功:

image.png


延升知识:

处理依赖关系

使用systemd时,可通过正确编写单元配置文件来解决其依赖关系。典型的情况是,单元A要求单元B在A启动之前运行。在此情况下,向单元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依赖关系是可选的,可添加 Wants=B 和 After=B。请注意 Wants= 和 Requires= 并不意味着 After=,即如果 After= 选项没有制定,这两个单元将被并行启动。 
依赖关系通常被用在服务(service)而不是目标(target)上。例如, network.target 一般会被某个配置网络接口的服务引入,所以,将自定义的单元排在该服务之后即可,因为 network.target 已经启动。


猜您喜欢