问题描述
我在两种情况下都要求：技术上和风格上。
我的应用程序/守护程序可以在/opt/my_app/run/中保留pid文件吗？
这样做真的很糟糕吗？
我的需要是：我的守护进程在特定用户下运行，并且实现者必须在/var/run中创建一个新目录，然后chgrp它以使我的守护进程运行。似乎更容易将pidfile保持为本地(对守护进程)。
最佳解决方案
我不会在应用程序安装目录下放置一个pidfile，例如/opt/my_app/whatever。这个目录可以挂载read-only，可以在机器之间共享，可以被守护进程监视，该守护进程可以将任何变化视为可能的break-in尝试……
pidfiles的正常位置是/var/run。大多数unices将在启动时清理此目录;在Ubuntu下，这是通过/var/run和in-memory文件系统(tmpfs)实现的。
如果从以root身份运行的脚本启动守护程序，请让它创建一个子目录/var/run/gmooredaemon，然后在su用户启动守护程序之前将其输入到daemon-running用户。
在许多现代Linux系统上，如果从未以root身份运行的脚本或启动程序启动守护程序，则可以将pid文件放在/run/user/$UID中，这是与传统/var/run等效的per-user。请注意，启动程序的根部分或以root身份运行的引导脚本需要创建目录(对于人类用户，在用户登录时创建目录)。
否则，在/tmp或/var/tmp下选择一个位置，但这会带来额外的复杂性，因为如果pidfile的名称位于world-writable目录中，则无法唯一确定该名称。
在任何情况下，让分销商或管理员轻松(命令行选项，加上可能是compile-time选项)来更改pidfile位置。
次佳解决方案
/opt用于安装’self-contained’应用程序，所以这里没有错。使用/opt/my_app/etc/作为配置文件，使用/opt/my_app/log/作为日志等 – 这种应用程序的常用做法。
您可以将应用程序分发为TGZ文件，而不是为每个软件包管理器维护一个软件包(自标记ubuntu以来至少为DEB)。我建议将此用于in-house应用程序或您可以很好地控制环境的情况。原因在于，如果安全成本高于您所使用的内容，则无关紧要(打包应用程序所需的工作不应超过编写应用程序所需的工作量)。
第三种解决方案
pid文件的位置应该是可配置的。 /var /run是pid文件的标准，与/var /log相同是日志的标准。但是您的守护程序应该允许您在某个配置文件中覆盖此设置。
第四种方案
如果您没有以root身份运行脚本，另一个约定是将pid文件放在~/.my_app/my_app.pid中。这种方式更简单，同时仍然是安全的，因为主目录不是world-writeable。