线上编译了一个Nginx，通过命令行来启停，一次服务器重启，Nginx忘记启动，导致网页不能访问。于是决定让Systemd来管理Nginx的启停，写了Service Unit文件，如下，

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

将文件拷贝到目录“/usr/lib/systemd/system”下，重载Systemd配置，

systemctl daemon-reload

当执行启动命令后，

systemctl start nginx

发现执行长时间卡着，没有返回。

检查了一遍Unit文件的内容，Type指令的值配置为“forking”，没有问题，因为由ExecStart配置的Nginx主进程“/usr/local/nginx/sbin/nginx”启动时会创建子进程而自身会变成进程管理者（有些服务主进程会退出），当Type的值为“forking”时，需要配置指令PIDFile，它的值是一个文件，包含完整路径，文件内容是进程的PID，这样Systemd就能追踪和管理该Service。

当执行“systemctl status nginx”时，发现异常。

经过查询得知Systemd不会自动创建PID文件，该文件由Nginx自己创建，检查Nginx的配置文件发现下面片段，

这是一个相对路径，Pid文件的绝对路径为“/usr/local/nginx/logs/nginx.pid”，更新service unit配置文件中PIDFile的值，重新reload后，启动Nginx发现正常了。

Type还有一个常用的值为“simple”，这种情况下，由ExecStart指定的主进程不会forking也不自动退出，在服务的整个生命周期主进程一直运行，比如一些由Node.js编写的应用或者一些使用Flask编写的应用（默认运行在前台，没有采用守护进程的方式运行）。