daemon(0, 0) incrementing process ID

I came across this annoyance some time ago, but it has just bit me again in
the last couple of days. I have a Cocoa application which starts a C daemon
using NSTask. I need to keep track of the daemon, and getting its PID is
fairly important. Unfortunately I would always get an off by one error with
this code:

NSTask *daemon = [NSTask launchedTaskWithLaunchPath:daemonPath
arguments:[self getDaemonStartArgs]];
daemonPID = [daemon processIdentifier];

So I wrote this test app:

#include <stdio.h>
#include <unistd.h> // fork()
#include <sys/types.h>

int main(int argc, char* argv[])
{
printf("PID is: %d\n", getpid());

daemon(0, 0);

FILE *outFile = fopen("/Users/liteyear/daemonPIDoutput", "w");
fprintf(outFile, "PID is: %d", getpid());

return 0;
}

And sure enough, the PID in daemonPIDoutput was always one higher than the
one printed to stdout. I searched for confirmation of this, but couldn't
find documentation to that effect. Nonetheless, it was very repeatable, so
I just added 1 to the [daemon processIdentifier] value. I was worried
however, about the PID looping or skipping values, and sure enough, in
Panther I came across a big problem. Just after my daemon started,
fix_prebinding would often start, meaning the PID the daemon ends up is 2
higher than that reported by -processIdentifier.

I tried delaying the call to -processIdentifier, or speeding up the call to
daemon, neither of which would be very robust, and neither of which
actually worked.

In the end, I made the daemon write its PID to a file (in /tmp because
non-root apps can't write to /var/run) just after it becomes a daemon. The
Cocoa application then checks the status of this file every second or so.

I'm after confirmation that the call to daemon gets a new PID, and
suggestions on how to work around this.

Cheers!
--
*--------------------------------------------------------*
| ^Nothing is foolproof to a sufficiently talented fool^ |
| Heath Raftery, HRSoftWorks _\|/_ |
*______________________________________m_('.')_m_________*

In article <bu7nvj$9n$2@seagoon.newcastle.edu.au>,
Heath Raftery <hraftery.TakeThisOut@myrealbox.com> wrote:

 > So I wrote this test app:
 >
 > #include <stdio.h>
 > #include <unistd.h> // fork()
 > #include <sys/types.h>
 >
 > int main(int argc, char* argv[])
 > {
 > printf("PID is: %d\n", getpid());
 >
 > daemon(0, 0);
 >
 > FILE *outFile = fopen("/Users/liteyear/daemonPIDoutput", "w");
 > fprintf(outFile, "PID is: %d", getpid());
 >
 > return 0;
 > }
 >
 > And sure enough, the PID in daemonPIDoutput was always one higher than the
 > one printed to stdout. I searched for confirmation of this, but couldn't
 > find documentation to that effect.

 > I'm after confirmation that the call to daemon gets a new PID, and
 > suggestions on how to work around this.

You can find the source code for the daemon() implementation in Panther
at
<http://www.opensource.apple.com/darwinsource/10.3/Libc-320/gen/FreeBSD/d
aemon.c>.
If you look at that, you'll see that it calls fork(). That'll give the
process a new PID. There's no way to work around this. I don't think
there's a way to get the new PID, either, other than the file-writing
trick you mentioned.

Hope this helps a bit,
Eric

--
Eric Albert ejalbert.TakeThisOut@cs.stanford.edu
<a style='text-decoration: underline;' href="http://rescomp.stanford.edu/~ejalbert/" target="_blank">http://rescomp.stanford.edu/~ejalbert/</a><!-- ~MESSAGE_AFTER~ -->