当存在过时的PID文件时，python守护程序上下文无法启动

我使用的是python守护进程，问题是当我

kill-9

一个进程时，它会留下一个pidfile（ok），下次运行我的程序时，它不会工作，除非我已经手动删除了这个pidfile（不ok）

我捕获所有异常，以便在终止之前调用

context.close（）

——当发生这种情况时（例如在

kill

上），删除/var/run/mydaemon.pid*文件，并成功运行后续的守护进程。但是，当使用SIGKILL（

kill-9

）时，我没有机会调用

context.close（）

，并且/var/run文件仍然存在。在本例中，下次运行程序时，它不会成功启动——原始进程返回，但守护进程在

context.open（）

处阻塞

python守护进程似乎应该注意到，对于一个不再存在的进程，存在一个pidfile，并将其清除，但这并没有发生。我应该用手来做这个吗

注意：我没有对使用

，因为这段代码运行在Python 2.4上

from daemon import DaemonContext
from daemon.pidlockfile import PIDLockFile

context = DaemonContext(pidfile = PIDLockFile("/var/run/mydaemon.pid"))
context.open()

try:
    retry_main_loop()
except Exception, e:
    pass
context.close()

与脚本提供
正如您所说，pid文件仍保留在kill-9上，但脚本也会在重新启动时正确清理。
如果您正在运行linux，并且进程级锁是可接受的，请继续阅读

我们试图获得锁。如果失败，请检查锁是否由正在运行的进程获取。如果没有，请断开锁并继续

from lockfile.pidlockfile import PIDLockFile
from lockfile import AlreadyLocked

pidfile = PIDLockFile("/var/run/mydaemon.pid", timeout=-1)
try:
    pidfile.acquire()
except AlreadyLocked:
    try:
        os.kill(pidfile.read_pid(), 0)
        print 'Process already running!'
        exit(1)
    except OSError:  #No process with locked PID
        pidfile.break_lock()

#pidfile can now be used to create DaemonContext

编辑：看起来PIDLockFile只能在lockfile>=0.9上使用，这是两年前的事了，所以我的记忆很模糊，但是是的，我想我就是这么做的（我在问题中提到的“用手做这个”的意思）。标记为答案，因为为什么不。