SysV脚本要具备的能力

xhz

SysV脚本要具备的能力

要使用脚本管理服务进程，该脚本还要求具备以下能力，且处理逻辑越完善，脚本就越完美。

启动进程时：
要求能够检测进程是否已在运行。这包括检测pid文件是否存在、/proc目录下是否有进程pid值对应的目录。
应该为程序创建锁文件，路径一般在/var/lock/subsys目录下。
如果使用daemon函数启动进程，允许--user指定程序的运行身份。
有些进程启动时需要依赖于其他进程，如NFS启动时依赖于rpcbind服务、mountd服务等，所以在NFS脚本中必须能够检测并启动这些依赖服务。
关闭进程时：
要求能够检测进程是否已在运行。同样是检测pid文件是否存在，/proc目录下是否有pid对应的目录。要注意，只有/proc目录下没有了对应目录，才表示进程已死，但pid文件仍可能存在，例如kill -9就会出现这种问题。
可以使用functions文件中的killproc函数杀进程，也可以直接使用kill或killall。
为了让脚本更完善，杀进程时应该多次检测进程是否真的已经杀死。
杀死进程的最后，必须要删除pid文件和锁文件。
对于有依赖性的服务，考虑是否也应该杀死它们。
服务重读配置文件时(reload)：
对于非终端进程，发送HUP信号的作用是重读配置文件，而不会中断进程。
为了标准，应该找出”master”进程的pid，并向其发送HUP信号。一般来说，服务的子进程或线程不会也没必要读取配置文件。为了方便，可以直接向所有进程发送HUP信号。
最好在发送HUP信号前，也检查进程是否已在运行。当然，对于reload来说，这无所谓。
如果待管理程序支持配置文件的语法检查，在发送HUP信号前，应该检查语法是否错误。
实在无法实现重读配置文件的功能，应该让其和restart的功能一致，一般这也是”force-reload”的功能。
重启服务时：
一般来说，就是先stop，再start。
查看status时：
除非有额外的状态显示需求，否则/etc/init.d/functions中的status函数已经足够完美了。
以上并没有说明，管理多实例服务时的情况。这需要考虑额外的因素，例如程序自身是否支持多实例，支持的话是否应该写多个服务脚本分别管理各程序，配置文件是否要共享，pid文件是否能共享，搜索pid时如何避免搜索出非自身实例的pid，还要注意分配锁文件。这样的脚本写起来可能并不难，但这些因素必须要考虑。本文暂不介绍多实例的SysV脚本，因为和程序自身关联性比较强。

有了以上内容，并理解了functions文件中的函数，再看/etc/init.d/下的服务启动脚本，绝大多数都感觉很简单。因为它们的思路和框架都是一致的。

因为网上以及/etc/init.d/下服务启动脚本示例太多了，所以本文不单独写这类脚本，而是从几个脚本中抽出比较经典的部分，分别介绍start，stop，reload和status的写法。