PID lockfile

Cameron Simpson cs at
Sun Mar 29 04:10:43 CEST 2009

On 29Mar2009 11:37, Ben Finney <ben+python at> wrote:
| aahz at (Aahz) writes:
| > In article <87iqlwvemo.fsf at>,
| > Ben Finney  <bignose+hates-spam at> wrote:
| > >In the case of the ‘lockfile’ library, Skip is aiming for a
| > >cross-platform solution, with atomic behaviour; he has implemented
| > >lock acquisition with a ‘link’ operation on Unix, and a
| > >‘mkdir’ operation on Windows.

I've been using mkdir on UNIX for my own locks; also an NFS-safe
operation needing no file-level locks. I've also seen
open("lockfile",O_RDWR,0) suggested; since it atomicly makes a
non-writable file, only the first opener gets to succeed.

| > >But both of those, of course, create a new file. What I want is to
| > >lock an existing file. Is ‘lockf’ particularly prone to
| > >cross-platform troubles on Unix variants?

NFS can be run without a lock daemon, and I have vague recollections
of NFS lock daemons not talking to each other on different platforms
(eg Solaris vs Linux or Linux vs *BSD). I have no idea if that is still
a current issue.

| > IIUC, you must use something like Skip's trick to work correctly with
| > NFS.
| Okay. But is that something that needs to be accommodated with,
| specifically, PID file handling? Why would a PID file ever need to be
| on NFS storage instead of local?

If you're talking about a system daemon, maybe never; at any rate it is
rare. However there's plenty of occasions when I want to start a daemon,
as me, for my own personal purposes. It doesn't do any uid/gid juggling
or privilege dropping, but it's a perfectly reasonable thing to want to
use your daemon module to do everything else (detach, pid locks, etc).

Conbine that with "my home dir is NFS shared across our LAN" and you're
instantly into routine lockfile-on-NFS land.

I speak as one who was in that circumstance in my former life.

Cameron Simpson <cs at> DoD#743

NFS: Not a File System

More information about the Python-list mailing list