After looking at the code a little closer, it looks like there is a race condition in the 'alive' function in Proc::PID::File too, since it releases the lock after reading the PID, and then re-aquires the lock later for writing. The lock should be kept from the read right through to the write.

I ran into some other problems as well with perl 5.8.0 and Proc::Daemon. There appears to be a reference counting problem/bug in perl 5.8.0, which doesn't appear in 5.6.1. It has to do with the POSIX::close function. The standard perl close function takes a File Handle, but the POSIX::close function takes a File Descriptor. If you open a file normally, and then close it's File Descriptor with POSIX::close, then perl will still think the file is open and linked to the File Descriptor that was just closed. For example:

open TEST, "+> /tmp/output";  # uses File Descriptor 3
POSIX::close(3);              # closes the file, but TEST
                              #  is still linked to FD 3
open TEST2, "+> /tmp/output2";# uses FD 3 since it is
                              #  avaliable again
print TEST "Testing\n";       # Will be written to output2
close TEST2;                  # does not close the file,
                              #  because perl thinks TEST
                              #  still has it open.
close TEST;                   # Now output2 is closed
                              #  and both file handles are
                              #  closed properly
[download]

This looks like a contrived example, but POSIX::close is used by Proc::Daemon to close all open files right after the fork and setsid occur. So if you have any open files before the fork they will be improperly closed. I had an __END__ block in my code which triggers the DATA filehandle to be opened for you (even though I didn't have __DATA__ in my code, the __END__ triggers it anyway).

Since DATA was only half closed, it ended up causing a deadlock in the Proc::PID::File call to 'alive' (I won't go into details why, since this post is getting long enough :).

It looks like I might have to roll my own code for this after all...