一般守护进程/服务器设计 - 最佳实践（C / C ++，Linux）

Question

这些问题非常普遍，因为它们在不同的情况下不断涌现。我希望有一些基本原则/标准做法。

典型要求：

1. 一个程序，就像一个“服务器”，在Linux中运行 背景（并且几乎不停地运行。可能每天或每周重启）
2. 通过某种套接字协议处理客户端连接
3. 具有启动配置文件
4. 输出到一个或多个日志文件

我的问题：

1. 我应该将程序编写为“守护程序”吗？选择守护程序与非守护程序路径时应该考虑哪些事项？
2. 在linux文件夹层次结构中，日志文件和配置文件应该去哪里？我应该从某个用户的主目录或某个用户​​主目录中的子文件夹中运行它吗？或者我应该创建一个新文件夹，即/ my_server_abc /然后从那里运行它，也将日志文件写入该目录？

由于

Answer 1

  

  
1. 我应该将程序编写为“守护程序”吗？
  

没有

不要试图让自己守护。使用操作系统配置的工具使您的应用程序在启动脚本的后台运行，例如Debian / Ubuntu中的start-stop-daemon。 Systemd和upstart也可以在他们的启动脚本中为你处理这个问题，如今大多数初始化系统也是如此。

编写一个守护进程有一些你可能不会想到的陷阱，并且大多数现代的init脚本都不希望你将自己的进程发送到后台 - 这无论如何都会使他们的工作复杂化。这允许生成可靠的.pid文件以跟踪应用程序的进程ID。如果你自己守护，你的init系统必须依靠你的应用程序以某种方式正确地传递你的进程id，因为你生成新的PID，init系统无法跟踪。这对他们来说都很复杂。

Answer 2

1. 使用libdaemon。
2. 关注Filesystem Hierarchy Standard。

Answer 3

你应该编写一个真正的守护进程（后台的fork和发布tty）。这使得在系统启动时轻松运行软件是最佳实践。

对于日志记录，您应将日志保留在默认位置：/var/log。您甚至可能希望使用syslog进行日志记录，因为它是linux下的默认值，您无需关心日志文件处理。

Answer 4

我知道你在问这个问题时正在考虑c / c ++，但我认为它比这更普遍，设计时使用的逻辑独立于实现所用的语言。

有一个python增强提议（PEP 3143），用于描述现在已成为该语言一部分的标准守护进程库。如果您查看有关正确守护程序行为的this部分，它将描述守护程序应如何操作。还需要考虑“服务”和守护进程之间的差异。

我认为应该很好地回答关于守护进程及其行为的一般问题。查看W. Richard Stevens' Home Page，您可以找到有关'Unix网络编程'的信息，Prentice Hall在* nix环境和最佳实践中编写守护进程时，有更多关于c / c ++的信息。