init.d 守护进程脚本中的锁文件用途 (linux)

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 对于除进程的直接父进程之外的任何进程都没有意义；任何其他用途都有无法解决且危险的竞争条件（即您最终可能会杀死另一个不相关的进程）。不幸的是，这种设计不当（或者更确切地说是未经设计）的黑客行为是大多数 UNIX 系统上的标准做法……

有几种方法可以正确解决该问题。一种是 systemd 方法，但 systemd 在某些圈子中并不受欢迎，因为它“臃肿”并且难以使用远程 /usr首次启动后安装。在任何情况下，解决方案将涉及：

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

无论如何，lockfile/pidfile 方法是丑陋的、容易出错的，并且几乎不比简单的 killall foobard 这样的懒惰方法更好（这当然也是错误的）。

Answer 2

“lockfile”变量的作用是什么？

它可能什么都没有，也可能是例如。通过此行注入到 $OPTIONS

   . /etc/sysconfig/ntpd

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

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

？ /etc 中不应该有二进制文件，并且习惯上编辑 /etc/init.d 脚本来更改配置。二进制文件应转到 /(s)bin 或 /usr/(s)bin。

Answer 3

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