在Unix上正确处理PID文件的参考
我在哪里可以find一个备受尊敬的参考资料 ，详细介绍在Unix上正确处理PID文件的情况？
在Unix操作系统上，通常使用一个特殊的locking文件“locking”一个程序（通常是一个守护进程）：PID文件。
这是一个位于可预测位置的文件，通常是“/var/run/foo.pid”。 程序应该检查何时启动PID文件是否存在，如果文件存在，则退出并报错。 所以这是一种咨询，协作的locking机制。
该文件包含一行文本，是当前持有锁的进程的数字进程ID（因此称为“PID文件”）; 这允许一个简单的方法来自动发送信号到持有锁的进程。
我无法find的是处理PID文件的预期或“最佳实践”行为的一个很好的参考。 有很多细微差别：如何实际上locking文件（不要打扰？使用内核？关于平台不兼容性？），处理失效的锁（静静地删除它们？何时检查？），何时准确获取和释放锁等等。
我在哪里可以find一个受人尊敬的，最权威的参考资料 （最好在W. Richard Stevens的水平上）来讨论这个小题目？
据我所知，PID文件是一个惯例，而不是你可以find一个受人尊敬的，主要是权威的来源。 我能find的最接近的是Filesystem Hierarchy Standard的这一部分 。
这个Perl库可能是有帮助的，因为它看起来像作者至less考虑了一些问题，而不是可能出现的问题。
我相信/ var / run下的文件通常由发行版维护者而不是守护进程的作者来处理，因为发行版维护者有责任确保所有init脚本一起运行良好。 我检查了Debian和Fedora的开发人员文档，找不到任何详细的指导方针，但您可能能够获得有关其开发人员邮件列表的更多信息。
首先，在所有现代的UNIX上， /var/run在重新启动时不会持续。
处理PID文件的一般方法是在初始化过程中创build它，并从任何出口（正常或信号处理程序）中删除它。
有两种规范的方法来自动创build/检查文件。 现在主要的是用O_EXCL标志打开它：如果文件已经存在，调用失败。 旧的方法（在没有O_EXCL系统上是强制的）是用一个随机的名字创build它并链接到它。 如果目标存在，链接将失败。
请参阅Kerrisk的Linux编程接口 ，第55.6节“运行一个程序的一个实例” ，它基于Stevens的Unix Network Programming v2中的pidfile实现。
还要注意，pidfile的位置通常是由发行版（通过初始化脚本）处理的，所以编写好的守护进程将使用命令行参数来指定pid文件，而不会被configuration文件意外覆盖。 它也应该优雅地处理一个陈旧的pid文件（O_EXCL不应该被使用）。 应该使用fcntl（）文件locking – 你可以假定守护进程的pid文件位于本地（非NFS）文件系统上。
根据分布，它实际上是处理pidfile的init脚本。 它在启动时检查存在，停止时删除等。我不喜欢这样做。 我写我自己的初始化脚本，通常不使用标准初始化函数。
一个写得很好的程序（守护进程）将会有一些configuration文件说明这个pidfile（如果有的话）应该写在哪里。 它也将注意build立信号处理程序，以便在正常或exception退出时清理PID文件，只要可以处理信号。 然后，PID文件为init脚本提供正确的PID，以便停止。
因此，如果pidfile在启动时已经存在，那么它对于之前崩溃的程序来说是非常好的指示器，并且应该做一些恢复工作（如果适用的话）。 如果你有初始化脚本本身检查PID的存在，或者取消它的链接，那么你可以在脚上执行这个逻辑。
就名称空间而言，它应该遵循程序名称。 如果你开始“食物（foo守护进程）”，那就是food.pid
你也应该探索/ var / lock / subsys，但是这主要用在Red Hat的风格上。
