【发布时间】:2011-07-07 14:45:51
【问题描述】:
我在两种情况下都问:技术上和风格上。
我的应用程序/守护进程可以在/opt/my_app/run/ 中保留一个 pidfile 吗?
这样做很糟糕吗?
我的需要是:我的守护进程在特定用户下运行,实现者必须在/var/run 中创建一个新目录,chown 和 chgrp 以使我的守护进程运行。将 pidfile 保持在本地(对守护程序)似乎更容易。
【问题讨论】:
我在两种情况下都问:技术上和风格上。
我的应用程序/守护进程可以在/opt/my_app/run/ 中保留一个 pidfile 吗?
这样做很糟糕吗?
我的需要是:我的守护进程在特定用户下运行,实现者必须在/var/run 中创建一个新目录,chown 和 chgrp 以使我的守护进程运行。将 pidfile 保持在本地(对守护程序)似乎更容易。
【问题讨论】:
我不会将 pidfile 放在应用程序安装目录下,例如 /opt/my_app/whatever。该目录可以只读方式挂载,可以在机器之间共享,可以被守护进程监视,该守护进程将那里的任何更改视为可能的入侵尝试……
pidfiles 的正常位置是/var/run。大多数 unice 会在启动时清理这个目录;在 Ubuntu 下,这是通过 /var/run 内存中文件系统 (tmpfs) 实现的。
如果您从以 root 身份运行的脚本启动您的守护程序,请让它创建一个子目录 /var/run/gmooredaemon 并在 su 发送给用户并启动守护程序之前将其分配给运行守护程序的用户。
在许多现代 Linux 系统上,如果您从不是以 root 身份运行的脚本或启动器启动守护程序,您可以将 pidfile 放在 /run/user/$UID 中,这是传统 /var/run 的每个用户等效项.请注意,启动器的 root 部分,或以 root 身份运行的引导脚本需要创建目录(对于人类用户,该目录是在用户登录时创建的)。
否则,请在/tmp 或/var/tmp 下选择一个位置,但这会带来额外的复杂性,因为如果pidfile 的名称在一个全局可写目录中,则无法唯一确定它。
无论如何,让分发者或管理员更容易(命令行选项,加上编译时选项)更改 pidfile 位置。
【讨论】:
/run/user 中创建一个每个用户的目录。我不记得/run 本身是每个人都可以写的。但是/run 中的 pidfiles 很常见,尽管如此,它们是系统服务的规范。 pidfile 由以 root 身份运行的主管编写,或者由以 root 身份运行的启动脚本在启动具有可能降低的权限的实际守护程序之前编写。
/run/user/$UID 仅在会话期间存在(或多或少在用户登录时)。请改用 /tmp 或 ~,请参阅:superuser.com/a/1127720/71795
pid 文件的位置应该是可配置的。 /var/run 是 pid 文件的标准,就像 /var/log 是日志的标准一样。但是你的守护进程应该允许你在一些配置文件中覆盖这个设置。
【讨论】:
/opt 用于安装“自包含”应用程序,所以这里没有错。使用/opt/my_app/etc/ 用于配置文件,/opt/my_app/log/ 用于日志等等——这种应用程序的常见做法。
这样您就可以将您的应用程序作为 TGZ 文件分发,而不是为每个包管理器维护一个包(至少是 DEB,因为您标记了 ubuntu)。对于内部应用程序或您可以很好地控制环境的情况,我建议您使用此方法。理由是,如果保险箱的成本高于您放入的保险箱的成本(打包应用程序所需的工作不应超过编写应用程序所需的工作量)是没有意义的。
【讨论】:
另一个约定,如果您不是以 root 身份运行脚本,则将 pidfile 放在 ~/.my_app/my_app.pid 中。这种方式更简单,同时仍然安全,因为主目录不是全局可写的。
【讨论】: