问题标签 [python-daemon]

我正在尝试使用python-daemon库，这在我看来是创建守护程序而不忘记任何东西的最安全方法。文档很差，只是PEP 3143。

另一方面，我发现了很多指向 Sander Marechal 的A simple unix/linux daemon in Python的链接。这看起来是一个更好的解决方案，或者虽然我还没有尝试使用它。

编辑：我使用了 Sander Marechal 的解决方案，它似乎工作得很好。

那么在 Python 社区中创建守护进程的实际方式是什么，是这些库之一，还是只是自己做所有事情（分叉两次等）？

此外，您会认为任何具有 PE​​P 的库都是更好的选择，因为它比任何其他解决方案更接近于创建守护程序的综合方式（或至少是更标准的方式）。那么这个python-daemon包是怎么回事，它会被包含在标准库中吗？

我需要不时使用fabfile远程启动远程盒子中的一些程序，并得到结果。由于程序需要很长时间才能完成，我希望让它在后台运行，所以我不需要等待。所以我尝试了 os.fork() 让它工作。问题是，当我 ssh 到远程框，并在那里使用 os.fork() 运行程序时，程序可以在后台正常工作，但是当我尝试使用 fabfile 运行时，sudo 远程启动程序，os. fork() 不能工作，程序只是默默地死掉。所以我切换到 Python-daemon 来守护程序。很长一段时间，它工作得很好。但是现在当我开始让我的程序读取一些 Python 搁置字典时，python-daemon 不能再工作了。好像如果你使用 python-daemon，搁置的字典不能正确加载，我不知道为什么。

我使用python-daemon库在 python 中实现了一个守护进程。

然而，守护进程似乎会周期性地死亡（或被杀死），其中周期性地从一天到几个月不等。

我试图通过捕获异常、将它们记录到文件并将它们邮寄给我来找到守护进程死亡的原因。我的脚本的守护进程部分大致如下：

我已经记录了很多异常并邮寄给我，所以我知道代码通常可以工作。

在大多数情况下，我什么也得不到，看门狗脚本会提醒我守护程序不再运行。有什么方法可以找出或跟踪守护进程死亡或被杀死的原因吗？

我正在尝试设置一个工作守护程序来处理来自 rabbitmq 的消息。我正在使用 pika 及其 SelectConnection。如果我不将其作为守护程序运行，则该代码可以正常工作。我可以用

和

成功地。但是，当我添加

到worker.py，代码虽然没有引发任何异常，但会停止从队列中获取消息并最大化我的CPU利用率。worker.py 看起来和这个例子一模一样。

谢谢。

我正在使用 mod_wsgi 通过 Apache 为 django 站点提供服务。我还有一些作为后台进程运行的 Python 代码（dameon？）。它不断轮询服务器并将数据插入其中一个 Django 模型。这工作正常，但我可以让这段代码成为我的 Django 应用程序的一部分，并且能够在后台持续运行吗？它本身不需要是一个过程，而是不断活跃的 Django 站点的艺术。如果是这样，您能否指出一个示例或一些可以帮助我完成此任务的文档？

谢谢。

我正在尝试使用依赖于 python-daemon 的 python 库（python_openid）。后者似乎不适用于 Windows。

我有什么选择（没有安装 Linux）？

好的，我已经查看了 python-daemon，以及其他各种与守护程序相关的代码配方。是否有任何“hello world”教程可以帮助我开始使用基于 python 的守护进程？

我在使用 python-daemon 1.6和 APScheduler 来管理任务列表时遇到问题。

（调度程序需要在特定选择的时间定期运行它们 - 秒分辨率）

工作（直到按下 Ctrl+C），

样本输出：

INFO：apscheduler.threadpool：已启动线程池，核心线程数为 0，最大线程数为 20 等到添加作业 INFO：apscheduler.scheduler：已将作业“job_function（触发器：interval [0:00:30]，下次运行时间：2011-10-06 18:30:39）”添加到作业存储“默认”信息：apscheduler.scheduler：将作业“job_function（触发器：interval[0:00:30]，下次运行时间：2011-10-06 18:30:33）”添加到作业存储“默认”调试：apscheduler.scheduler：寻找要运行的作业 DEBUG:apscheduler.scheduler:下一次唤醒到期时间为 2011-10-06 18:30:33（在 10.441128 秒内）

使用 python-daemon， 输出为空白。为什么 DaemonContext 不能正确生成进程？

编辑 - 工作

在阅读了 python-daemon 源代码后，我将 stdout 和 stderr 添加到了 DaemonContext 中，终于能够知道发生了什么。

我目前正在编写一个 Python 守护进程，它实时监控日志文件并根据结果更新 Postgresql 数据库中的条目。该过程只关心出现在日志文件中的唯一键以及从该键中看到的最新值。

我正在使用轮询方法，每 10 秒处理一个新批次。为了减少整个数据集以避免对数据库进行无关更新，我只将键和最新值存储在字典中。根据过去 10 秒内的活动量，此字典可能包含 10-1000 个唯一条目。然后 dict 得到“处理”并将这些结果发送到数据库。

我主要关心的是内存管理和随着时间的推移（几天、几周等）的字典。由于这是一个不断运行的守护进程，内存使用量会根据字典的大小而膨胀，但不会适当缩小。我尝试使用标准取消引用重置 dict，并在处理批处理后使用 dict.clear() 方法，但注意到内存使用没有变化（FreeBSD/top）。似乎强制 gc.collect() 确实恢复了一些内存，但通常只有 50% 左右。

你们对我应该如何进行有什么建议吗？在我的过程中我还能做些什么吗？如果您看到围绕该问题的不同道路，请随时加入 :)

我正在使用python-daemon，并且遇到一个问题，当我kill -9处理一个进程时，它会留下一个pidfile（好的），并且下次我运行我的程序时它不起作用，除非我已经手动删除了pidfile（不是行）。

context.close()我按照在终止之前调用的顺序捕获所有异常——当这种情况发生时（例如在 a 上kill），/var/run/mydaemon.pid* 文件被删除并且后续的守护进程运行成功。但是，当使用 SIGKILL ( kill -9) 时，我没有机会调用context.close()，并且 /var/run 文件仍然存在。在这种情况下，下次我运行我的程序时，它没有成功启动——原始进程返回，但守护进程在context.open().

似乎 python-daemon 应该注意到一个进程的 pidfile 不再存在，并将其清除，但这并没有发生。我应该手动做这个吗？

注意：我没有使用with，因为此代码在 Python 2.4 上运行