0

查看 /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'？）

4

3 回答 3

2

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

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

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

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

于 2011-10-01T16:27:36.880 回答
1

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

于 2011-10-01T15:41:16.307 回答
1

'lockfile' 变量在做什么？

它可能什么都不是，也可能是例如。$OPTIONS由这条线注入

   . /etc/sysconfig/ntpd

守护进程选择可以去-p pidfile哪里$lockfile。守护程序将其写入$PID此文件。

我是直接将编译后的二进制文件放在 /etc/init.d/ 中还是在其中放置一个调用二进制文件的脚本

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

于 2011-10-01T15:55:40.143 回答