Question

在查看/etc/init.d/中的各种守护程序脚本时，我似乎无法理解'lockfile'变量的用途。在启动守护进程之前，似乎没有检查'lockfile'变量。

例如，来自/etc/init.d/ntpd的一些代码：

prog=ntpd
lockfile=/var/lock/subsys/$prog

start() {
        [ "$EUID" != "0" ] && exit 4
        [ "$NETWORKING" = "no" ] && exit 1
        [ -x /usr/sbin/ntpd ] || exit 5
        [ -f /etc/sysconfig/ntpd ] || exit 6
        . /etc/sysconfig/ntpd

        # Start daemons.
        echo -n $"Starting $prog: "
        daemon $prog $OPTIONS
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch $lockfile
        return $RETVAL
}

什么是'lockfile'变量？

另外，在C ++中编写我自己的守护进程时（例如跟在http://www.itp.uzh.ch/~dpotter/howto/daemonize底部的示例），我是否将编译后的二进制文件直接放在/etc/init.d/中，或者我是否放了一个脚本在那里调用二进制文件。（即通过调用我的二进制文件替换上面代码中的'daemon $ prog'）。

Answer 1

整个事情是一个非常脆弱和误导的尝试，以跟踪一个给定的守护进程是否正在运行，以便知道是否/如何在以后关闭它。使用pids没有帮助，因为除了进程的直接父进程之外，pid对任何进程都没有意义;任何其他用途都有无法解决和危险的竞争条件（即你最终可能会杀死另一个无关的进程）。不幸的是，这种设计不合理（或非常不合适）的hackery是大多数unix系统的标准做法......

有几种方法可以正确解决问题。一种是systemd方法，但systemd在某些圈子中不喜欢“膨胀”，并且难以在初始启动后使用远程/usr。在任何情况下，解决方案都将涉及：

使用主进程将所有守护进程生成为直接子进程（即在各个守护进程中禁止“守护进程”），从而可以使用它们的pid来监视它们的退出，跟踪它们的状态，并根据需要杀死它们
安排每个守护进程继承一个无用的文件描述符，只有在进程终止时才会保持打开和原子关闭。管道（匿名或命名为fifos），套接字甚至是普通文件都是可能的，但是一旦“另一端”关闭就给出EOF的文件类型是最合适的，因为它可以阻止等待这种状态。对于普通文件，可以使用链接计数（来自stat），但没有重复轮询就无法等待它。

在任何情况下，lockfile / pidfile方法都很丑陋，容易出错，并且几乎没有比简单killall foobard等懒惰方法更好的方法（当然这也是错误的）。

Answer 2

rc脚本会跟踪它是否正在运行，并且不会停止停止未运行的内容。

Answer 3

什么是'lockfile'变量？

它可能是什么，或者它可能是例如。通过此行注入$OPTIONS

   . /etc/sysconfig/ntpd

守护程序采用-p pidfile可以选择的$lockfile选项。守护程序将其$PID写入此文件中。

我是否将编译后的二进制文件直接放在/etc/init.d/中，或者我在那里调用二进制文件

后者。 /etc中不应包含二进制文件，并且通常会编辑/etc/init.d脚本以进行配置更改。二进制文件应转到/(s)bin或/usr/(s)bin。

init.d守护程序脚本中的lockfile目的（linux）

3 个答案: