由于最近练习用的机器上装的东西开的服务繁杂，而且很少重启，今天在查询sendmail服务器时，出现如上提示：

[root@master ~]# /etc/init.d/sendmail status
sendmail 已死，但是 subsys 被锁

这样解决的，我直接复制命令行了，关于/var/lock/subsys文件的作用在文章最后，网上找来的。

 

[root@master ~]# cd /var/lock
[root@master lock]# rm -rf subsys/
[root@master lock]# /etc/init.d/sendmail status
sendmail 已停

[root@master lock]# /etc/init.d/sendmail start
启动 sendmail：                                            [确定]
touch: 无法触碰 “/var/lock/subsys/sendmail”: 没有那个文件或目录

[root@master lock]# /etc/init.d/sendmail start
启动 sendmail：
[root@master lock]# /etc/init.d/sendmail status
sendmail (pid  9430) 正在运行…
[root@master lock]# /etc/init.d/sendmail stop
关闭 sm-client：                                           [失败]
关闭 sendmail：                                            [确定]
rm: 无法删除 “/var/lock/subsys/sendmail”: 是一个目录

[root@master subsys]# rm -rf sendmail/
[root@master subsys]# /etc/init.d/sendmail start
启动 sendmail：                                            [确定]
启动 sm-client：                                           [确定]

是这样的，保持/var/locksubsys目录 即可，其中内容可以删掉。

/var/lock/subsys目录的作用的说明, 摘自网友 crknoob 对subsys目录的说明

很多程序需要判断是否当前已经有一个实例在运行，这个目录就是让程序判断是否有实例运行的标志，比如说xinetd，如果存在这个文件，表示已经有xinetd在运行了，否则就是没有，当然程序里面还要有相应的判断措施来真正确定是否有实例在运行。通常与该目录配套的还有/var/run目录，用来存放对应实例的PID，如果你写脚本的话，会发现这2个目录结合起来可以很方便的判断出许多服务是否在运行，运行的相关信息等等。

实际上，判断是否上锁就是判断这个文件，所以文件存在与否也就隐含了是否上锁。而这个目录的内容并不能表示一定上锁了，因为很多服务在启动脚本里用touch来创建这个加锁文件，在系统结束时该脚本负责清除锁，这本身就不可靠（比如意外失败导致锁文件仍然存在），我在脚本里一般是结合PID文件（如果有PID文件的话），从PID文件里得到该实例的PID，然后用ps测试是否存在该PID，从而判断是否真正有这个实例在运行，更加稳妥的方法是用进程通讯了，不过这样的话单单靠脚本就做不到了。