0x01 前言
在过去很长的一段时间里,我在centos7中仍然使用service来启动和停止我自行编译的PHP。在今天,我终于决定改用systemctl,以便更符合centos7的风格。
其实两种方式都是可以在centos7中使用的,而且都不会产生任何问题,只是我喜欢新的东西而已。
0x02 准备
首先,与往常一样,先编译好php。然后定位到源码目录中的sapi文件夹,以下是我的路径,请根据实际情况进行查看:
/root/codex/php/php-7.1.4/sapi/
这个目录中有一个名为fpm的文件夹,而这些内容都和你的编译参数相关联,所以这些文件会在编译的同时自动生成。
里面有两个文件是我们所需要的:
- service:init.d.php-fpm
- systemctl:php-fpm.service
我们可以分别查看文件的内容,先是init.d.php-fpm:
[root@web-t1 ~]# cat /root/codex/php/php-7.1.4/sapi/fpm/init.d.php-fpm ...以上省略... prefix=/usr/local/php7 exec_prefix=${prefix} php_fpm_BIN=${exec_prefix}/sbin/php-fpm php_fpm_CONF=${prefix}/etc/php-fpm.conf php_fpm_PID=${prefix}/var/run/php-fpm.pid ...以下省略...
这一部分记录着我编译时所指定路径。然后是php-fpm.service:
[root@web-t1 ~]# cat /root/codex/php/php-7.1.4/sapi/fpm/php-fpm.service # It's not recommended to modify this file in-place, because it # will be overwritten during upgrades. If you want to customize, # the best way is to use the "systemctl edit" command. [Unit] Description=The PHP FastCGI Process Manager After=network.target [Service] Type=simple PIDFile=/usr/local/php7/var/run/php-fpm.pid ExecStart=/usr/local/php7/sbin/php-fpm --nodaemonize --fpm-config /usr/local/php7/etc/php-fpm.conf ExecReload=/bin/kill -USR2 $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target
这个文件内也同样记录着相关的路径和信息。
0x03 service
只需要将这两个文件放置到指定的位置即可实现功能,但一般在service和systemctl之间选其中一个即可。
首先是service。将init.d.php-fpm复制到指定位置:
[root@web-t1 ~]# cp /root/codex/php/php-7.1.4/sapi/fpm/init.d.php-fpm /etc/init.d/php-fpm7
随后即可使用service进行管理:
#启动 [root@web-t1 ~]# service php-fpm7 start #重启 [root@web-t1 ~]# service php-fpm7 restart #停止 [root@web-t1 ~]# service php-fpm7 stop #重新加载 [root@web-t1 ~]# service php-fpm7 reload #设为开机启动 [root@web-t1 ~]# chkconfig php-fpm7 on #查看开机启动信息 [root@web-t1 ~]# chkconfig | grep php php-fpm7 0:off 1:off 2:on 3:on 4:on 5:on 6:off
0x04 systemctl
接下来是systemctl,同样地将相关文件放置到指定位置:
[root@web-t1 ~]# cp /root/codex/php/php-7.1.4/sapi/fpm/php-fpm.service /usr/lib/systemd/system/
然后通过以下命令查看相关状态:
[root@web-t1 ~]# systemctl status php-fpm.service ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: inactive (dead)
从上面返还的信息可以得知,php-fpm的开机启动状态是出于禁用的。请注意第3行中的第1个disable,disable和enable分别表示开机启动已禁用和已启用:
下面是其他功能:
#启动 [root@web-t1 ~]# systemctl start php-fpm.service #重新启动 [root@web-t1 ~]# systemctl restart php-fpm.service #重新加载 [root@web-t1 ~]# systemctl reload php-fpm.service #开机启动 [root@web-t1 ~]# systemctl enable php-fpm.service Created symlink from /etc/systemd/system/multi-user.target.wants/php-fpm.service to /usr/lib/systemd/system/php-fpm.service. #检查开机启动 [root@web-t1 ~]# systemctl status php-fpm.service ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled) Active: inactive (dead)
这里要注意的是,如果php-fpm因为配置文件错误而导致无法启动,有可能没有任何错误信息弹出,这时候就需要使用status进行查看状态。以下是启动成功的状态:
[root@web-t1 ~]# systemctl status php-fpm.service ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2017-04-18 00:34:19 CST; 1s ago Main PID: 4244 (php-fpm) CGroup: /system.slice/php-fpm.service ├─4244 php-fpm: master process (/usr/local/php7/etc/php-fpm.conf) └─4245 php-fpm: pool webt1tcom
0x05 结语
我的其他软件都是用systemctl进行管理,一开始从service转过来时还有些不适应,但用过一段时间后,感觉systemctl确实比service要好。systemctl有以下功能:
[root@web-t1 ~]# systemctl add-requires condstop edit halt is-failed list-dependencies mask reload-or-restart set-environment status unset-environment add-wants daemon-reexec emergency help isolate list-jobs poweroff reload-or-try-restart set-property stop cancel daemon-reload enable hibernate is-system-running list-sockets preset rescue show suspend cat default exit hybrid-sleep kexec list-timers reboot reset-failed show-environment switch-root condreload delete force-reload is-active kill list-unit-files reenable restart snapshot try-restart condrestart disable get-default is-enabled link list-units reload set-default start unmask