问题:

今天在写centos7的systemctl 服务是,遇到一个坑,表现为当我执行systemctl命令后shell阻塞在那里,没有像平时执行命令那样自动结束(只能自己按Ctrl+C强制结束),效果如下:

centos 读取数据时系统卡 centos system halted卡住_服务进程

强制结束后,查看程序发现目标程序启动是成功的, 但状态为activating (start)而不是activating (running)态:

centos 读取数据时系统卡 centos system halted卡住_服务进程_02

hello.service服务代码如下:

[Unit]
Description=Hello service

[Service]
Type=forking
User=root
Group=root
ExecStart=/usr/bin/python /root/hello.py
Restart=always

[Install]
WantedBy=multi-user.target

hello.py代码为:

#coding:utf-8
import time

while True:
    time.sleep(5)

解决方法:

导致此问题的原因是:hello.service类型选择有问题, 不应该选forking类型;类型改为Type=simple(或删除Type=forking这句),问题便得到解决。

出现这个问题的可能原因,先看看type的种类和解释:

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=forking

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

Type=simple

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

从上表可以看到,当类型为forking时,systemd会认为所运行当该服务本身是守护进程即本身会fork,且只有父进程退出后systemd才会退出,但由于参考例子并不是守护进程,故systemd一直处于阻塞等待状态,默认的simple无等待这一环节。