c++ - init.d 守护程序脚本 (linux) 中的 lockfile 用途

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

整个事情是一个非常脆弱和误入歧途的尝试，试图跟踪给定的守护进程是否正在运行，以便知道以后是否/如何关闭它。使用 pid 没有帮助，因为 pid 对进程的直接父进程之外的任何进程都没有意义；任何其他用途都有无法解决和危险的竞争条件(即您可能最终会杀死另一个不相关的进程)。不幸的是，这种设计不当(或者更确切地说是未经设计)的 hackery 是大多数 unix 系统上的标准做法......

有几种方法可以正确解决问题。一种是 systemd 方法，但 systemd 在某些圈子中不受欢迎，因为它“臃肿”并且难以使用远程 /usr初始引导后安装。无论如何，解决方案将涉及:

1. 使用主进程生成所有守护进程作为直接子进程(即抑制单个守护进程内的“守护进程”)，从而可以使用他们的 pid 来监视他们退出，跟踪他们的状态，并根据需要杀死他们.
2. 安排每个守护进程继承一个原本无用的文件描述符，它将保持打开状态并仅作为进程终止的一部分自动关闭。管道(匿名或命名 fifos)、套接字，甚至普通文件都是可能的，但是一旦“另一端”关闭就给出 EOF 的文件类型是最合适的，因为有可能阻塞等待此状态。对于普通文件，可以使用链接计数(来自 stat)，但如果不重复轮询就无法等待它。

无论如何，lockfile/pidfile 方法是丑陋的、容易出错的，并且几乎不比简单的 killall foobard 等惰性方法好多少(当然这也是错误的)。