python-daemon

#4 pid locking fails to clean up stale pid file due to broken implementation in pylockfile
Closed: Duplicate by bignose. Opened by tenortim.

Closed: Duplicate
Reopen Issue

The pidfile implementation imported from openstack/pylockfile is incorrect and fails if the previous daemon dies and doesn't clean up the lockfile. The whole point of storing the PID in the file is to allow the acquire method to check if the PID still exists and continue if it does not. I don't know if this will get fixed in that library since it is marked as deprecated.

Example code from a much older daemon implementation by Ray Burr does "the right thing" viz:

def _checkPidFile(pidfile):
    str = pidfile.readline(100)
    if str == "":
        return None
    try:
        n = int(str)
    except ValueError:
        return None
    try:
        os.kill(n, 0)
    except os.error, (code, message):
        if code != errno.ESRCH:
            raise
        return None
    return n

If the pid file exists, you are supposed to send signal 0 to test for existence and if you get ESRCH, that PID is dead and you can continue.

The pidfile implementation imported from openstack/pylockfile is
incorrect

Thanks for the description.

Do you know of a PID file implementation that is better for ‘python-daemon’ to depend on?
Edited by bignose

"the right thing" mentioned above is not exactly right. The previous daemon may die and pid may be reused by some other process. The fact that there is a process this the same pid does not mean that daemon is running.
It looks like python-daemon does not keep the lock on a pidfile when daemon is running. That is the root cause of the problem. I'm not sure if that has anything to do with lockfile implementation. The lock should be ON all the time while daemon is running. It appears like python-daemon simply checks for pidfile existence upon startup somehow. Any insights?

I've done some more digging. lockfile 0.12.2 implementation is broken. It does not release the lock if process is terminated abnormally and that package is deprecated anyway, so there is no hope that it will ever be fixed.
fcntl.flock() would be a much better choice.

It looks like python-daemon does not keep the lock on a pidfile when
daemon is running.

The ‘python-daemon’ library does not implement locking at all.

The ‘DaemonContext’ accepts a ‘pidfile’; that object is a context manager, and ‘DaemonContext’ enters and exits that context manager.

The ‘DaemonContext’ describes the ‘pidfile’ option:

Context manager for a PID lock file. When the daemon context opens
and closes, it enters and exits the pidfile context manager.

So, the user of ‘DaemonContext’ can supply any ‘pidfile’ object which meets that API. The ‘lockfile’ library is used as a default implementation only.

Since there are reports that the ‘lockfile’ library is behaving poorly, I am open to a suggestion of a better PID file handler library that implements a context manager.
Edited by bignose

Metadata Update from @bignose:
- Issue tagged with: help-wanted, more-info

The issue of replacing the dependency on 'lockfile', is now addressed specifically in issue #42.

Metadata Update from @bignose:
- Issue close_status updated to: Duplicate
- Issue status updated to: Closed (was: Open)
Metadata
None

help-wanted more-info

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.