注意python-daemon包，它可以开箱即用地解决daemon背后的许多问题。

它支持的其他特性(来自Debian包描述)包括:

将进程分离到自己的进程组中。 设置适合在chroot中运行的进程环境。 放弃suid和sgid权限。 关闭所有打开的文件描述符。 修改工作目录、uid、gid和umask。 设置适当的信号处理程序。 打开stdin、stdout和stderr的新文件描述符。 管理指定PID锁文件。 注册用于出口处理的清理函数。

在python中进行daemonization时，还有一件需要考虑的事情:

如果您正在使用python日志记录，并且希望在守护进程完成后继续使用它，请确保在处理程序(特别是文件处理程序)上调用close()。

如果您不这样做，处理程序仍然可以认为它有文件打开，并且您的消息将简单地消失-换句话说，确保记录器知道它的文件是关闭的!

这假设当你守护进程时，你不加区别地关闭所有打开的文件描述符——相反，你可以尝试关闭除了日志文件以外的所有文件(但是关闭所有文件然后重新打开你想要的文件通常更简单)。

经过几年的努力和多次尝试(我尝试了这里给出的所有答案，但最后都有一些小缺点)，现在我意识到有一种比直接从Python启动、停止和重新启动守护进程更好的方法:使用OS工具。

例如，对于Linux，我不做python myapp start和python myapp stop，而是这样启动应用程序:

screen -S myapp python myapp.py    
# CTRL+A, D to detach

或者screen -dmS myapp python myapp.py在一个命令中启动和卸载它。

然后:

screen -r myapp

重新连接到这个终端。进入终端后，可以使用CTRL+C来停止它。

YapDi是一个python包。它可用于从脚本内部将python脚本转换为守护进程模式。

80%的情况下，当人们说“守护进程”时，他们只想要一个服务器。因为这个问题在这一点上是完全不清楚的，所以很难说答案的可能范围是什么。既然有一个服务器就足够了，那就从那里开始吧。如果实际需要一个“守护进程”(这种情况很少见)，请阅读nohup作为对服务器进行守护的一种方式。

在真正需要守护进程之前，只需编写一个简单的服务器。

再看看WSGI参考实现。

再看看简单HTTP服务器。

“还有其他需要考虑的事情吗?”是的。大概有一百万件事。什么协议?有多少请求?为每个请求服务多长时间?他们多久来一次?您会使用专用的流程吗?线程?子流程?编写一个守护进程是一项大工作。

因为python-daemon还不支持python3。我已经编写了PEP 3143的一个新实现:pep3143daemon

pep3143守护进程至少支持python 2.6、2.7和3.x

它还包含一个PidFile类。

该库仅依赖于标准库和六个模块。

它可以用作python-daemon的替代品。

这里是文档。