我的 pidfile 必须位于 /var/run 中吗？
我在两种情况下都在问：技术上和风格上。
我的应用程序/守护进程可以在 /opt/my_app/run/ 中保存 pidfile 吗？
这样做是不是很糟糕？
我的需求是这样的：我的守护进程在特定用户下运行，并且实现者必须在 /var/run 中 mkdir 一个新目录，chown 并 chgrp 它才能使我的守护进程运行。将 pidfile 保留在本地（对于守护进程）似乎更容易。
I'm asking in both contexts: technically and stylistically.
Can my application/daemon keep a pidfile in /opt/my_app/run/?
Is it very bad to do so?
My need is this: my daemon runs under a specific user, and the implementor must mkdir a new directory in /var/run, chown, and chgrp it to make my daemon run. Seems easier to just keep the pidfile local (to the daemon).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不会将 pidfile 放在应用程序安装目录下，例如
/opt/my_app/whatever。该目录可以只读方式安装，可以在机器之间共享，可以由守护进程监视，该守护进程将其中的任何更改视为可能的入侵尝试......pid 文件的正常位置是
/var/run。大多数 unice 会在启动时清理这个目录；在 Ubuntu 下，这是通过内存文件系统 (tmpfs) 来实现的。如果您从以 root 身份运行的脚本启动守护程序，请让它创建一个子目录
/var/run/gmooredaemon并在su之前将其 chown 给守护程序运行用户给用户并启动守护进程。在许多现代 Linux 系统上，如果您从不以 root 身份运行的脚本或启动器启动守护进程，则可以将 pidfile 放入
/run/user/$UID中，这是一个 per-用户相当于传统的/var/run。请注意，启动器的根部分或以根身份运行的引导脚本需要创建该目录（对于人类用户，该目录是在用户登录时创建的）。否则，请在
/tmp或/var/tmp下选择一个位置，但这会带来额外的复杂性，因为 pidfile 的名称无法唯一确定（如果它位于全局可写的文件中）目录。无论如何，让分发者或管理员可以轻松地（命令行选项，也许还有编译时选项）更改 pidfile 位置。
I wouldn't put a pidfile under an application installation directory such as
/opt/my_app/whatever. This directory could be mounted read-only, could be shared between machines, could be watched by a daemon that treats any change there as a possible break-in attempt…The normal location for pidfiles is
/var/run. Most unices will clean this directory on boot; under Ubuntu this is achieved by/var/runan in-memory filesystem (tmpfs).If you start your daemon from a script that's running as root, have it create a subdirectory
/var/run/gmooredaemonand chown it to the daemon-running user beforesuing to the user and starting the daemon.On many modern Linux systems, if you start the daemon from a script or launcher that isn't running as root, you can put the pidfile in
/run/user/$UID, which is a per-user equivalent of the traditional/var/run. Note that the root part of the launcher, or a boot script running as root, needs to create the directory (for a human user, the directory is created when the user logs in).Otherwise, pick a location under
/tmpor/var/tmp, but this introduces additional complexity because the pidfile's name can't be uniquely determined if it's in a world-writable directory.In any case, make it easy (command-line option, plus perhaps a compile-time option) for the distributor or administrator to change the pidfile location.
pid 文件的位置应该是可配置的。 /var/run 是 pid 文件的标准，与 /var/log 是日志的标准相同。但是您的守护进程应该允许您在某些配置文件中覆盖此设置。
The location of the pid file should be configurable. /var/run is standard for pid files, the same as /var/log is standard for logs. But your daemon should allow you to overwrite this setting in some config file.
/opt 用于安装“独立”应用程序，因此这里没有任何问题。使用
/opt/my_app/etc/作为配置文件，使用/opt/my_app/log/作为日志等 - 此类应用程序的常见做法。这样，您就可以将应用程序作为 TGZ 文件分发，而不是为每个包管理器维护一个包（至少是 DEB，因为您标记了
ubuntu）。我建议将其用于内部应用程序或您可以很好地控制环境的情况。原因是，如果保险箱的成本高于您放入的内容，则毫无意义（打包应用程序所需的工作不应超过编写应用程序所需的工作）。/opt is used to install 'self-contained' applications, so nothing wrong here. Using
/opt/my_app/etc/for config files,/opt/my_app/log/for logs and so on - common practice for this kind of application.This away you can distribute your applications as a TGZ file instead of maintaining a package for every package manager (at least DEB since you tagged
ubuntu). I would recommend this for in-house applications or situations where you have great control over the environment. The reasoning is that it makes no sense if the safe costs more than what you are putting inside (the work required to pack the application should not eclipse the effort required to write the application).如果您不以 root 身份运行脚本，另一个约定是将 pidfile 放入
~/.my_app/my_app.pid中。这种方式更简单，同时仍然安全，因为主目录不是全局可写的。Another convention, if you're not running the script as root, is to put the pidfile in
~/.my_app/my_app.pid. It's simpler this way while still being secure as the home directory is not world-writeable.