我在哪里可以找到一个备受推崇的参考资料，详细说明在 Unix 上正确处理 PID 文件？
在 Unix 操作系统上，通常的做法是使用特殊的锁定文件“锁定”程序（通常是守护进程）：PID 文件。
这是一个位于可预测位置的文件，通常是“/var/run/foo.pid”。程序应该在启动时检查 PID 文件是否存在，如果文件存在，则退出并出错。所以它是一种咨询、协作的锁定机制。
该文件包含单行文本，即当前持有锁的进程的数字进程 ID（因此称为“PID 文件”）；这允许一种简单的方法来自动向持有锁的进程发送信号。
我找不到关于处理 PID 文件的预期或“最佳实践”行为的良好参考。有各种细微差别：如何实际锁定文件（不要打扰？使用内核？平台不兼容怎么办？），处理陈旧的锁（静默删除它们？何时检查？），何时获取和释放锁，等等。
对于这个小话题，我在哪里可以找到受人尊敬、最权威的参考资料（最好是 W. Richard Stevens 的水平）？
首先，在所有现代 UNIX 上/var/run都不会在重新启动后持续存在。
处理 PID 文件的一般方法是在初始化期间创建它并从任何退出（正常或信号处理程序）中删除它。
有两种规范的方法可以原子地创建/检查文件。这些天主要是用O_EXCL标志打开它：如果文件已经存在，则调用失败。旧方法（在没有 的系统上是强制性的O_EXCL）是使用随机名称创建它并链接到它。如果目标存在，链接将失败。
请参阅 Kerrisk 的The Linux Programming Interface，第 55.6 节“只运行一个程序实例”，它基于 Stevens 的 Unix Network Programming, v2 中的 pidfile 实现。
另请注意，pidfile 的位置通常由发行版处理（通过 init 脚本），因此编写良好的守护程序将采用命令行参数来指定 pidfile，并且不允许它被配置文件意外覆盖。它还应该自己优雅地处理陈旧的 pid 文件（不应使用 O_EXCL）。应该使用 fcntl() 文件锁定——您可以假设守护程序的 pidfile 位于本地（非 NFS）文件系统上。
根据发行版，它实际上是处理 pidfile 的 init 脚本。它在启动时检查是否存在，在停止时删除等。我不喜欢那样做。我编写自己的初始化脚本，通常不使用标准初始化函数。
一个写得很好的程序（守护进程）会有某种配置文件，说明这个 pidfile（如果有的话）应该写在哪里。它还将注意建立信号处理程序，以便在可以处理信号时在正常或异常退出时清理 PID 文件。然后 PID 文件为 init 脚本提供正确的 PID，以便它可以停止。
因此，如果 pidfile 在启动时已经存在，它可以很好地指示程序之前崩溃并且应该进行某种恢复工作（如果适用）。如果您有 init 脚本本身检查 PID 的存在或取消链接，那么您有点在脚下拍摄该逻辑。
至于名称空间，它应该跟在程序名称之后。如果您正在启动 'foo-daemon'，它将是 foo-daemon.pid
您还应该探索 /var/lock/subsys，但它主要用于 Red Hat 风格。
Red Hat 7 上的systemd软件包提供了一个手册页daemon(7)，其标题行是“编写和打包系统守护程序”。
该手册页讨论了“旧式”（SysV）和“新式”（systemd）守护进程。在新风格中，systemd 本身会为您处理 PID 文件（如果配置为这样做）。但是，在旧式中，手册页有这样的说法：
- 在守护进程中，将守护进程 PID（由 getpid() 返回）写入 PID 文件，例如 /run/foobar.pid（对于假设的守护进程“foobar”），以确保守护进程不能多次启动. 这必须以无竞争方式实现，以便 PID 文件仅在验证之前存储在 PID 文件中的 PID 不再存在或属于外部进程时才更新。
您也可以在线阅读此手册页。