Hi, I'm not sure if there's a posix way of doing this, but wanted to
check if there is a way in linux.
I want to have a daemon that fork/execs a new process, but don't want
(for various reasons) the responsibility for cleaning up those process
with the wait() function family. I'm assuming that if the init process
became the parent of one of these forked processes, then it would clean
them up for me (is this assumption true?). Besides the daemon process
exiting, is there a way to disown the process on purpose so that init
inherits it?
Thanks,
Davy
On Fri, 2005-05-27 at 12:30 -0500, Davy Durham wrote:
> Hi, I'm not sure if there's a posix way of doing this, but wanted to
> check if there is a way in linux.
>
> I want to have a daemon that fork/execs a new process, but don't want
> (for various reasons) the responsibility for cleaning up those process
> with the wait() function family. I'm assuming that if the init process
> became the parent of one of these forked processes, then it would clean
> them up for me (is this assumption true?). Besides the daemon process
> exiting, is there a way to disown the process on purpose so that init
> inherits it?
Try man daemon.
The way I use to do it was simply do a double fork. That is
(simplified)...
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
/* child */
if ((pid = fork()) < 0) {
perror("child fork");
exit(-1);
} if (pid) {
/* child parent */
/* Here we detach from the child */
exit(0);
}
/* Now this code is a child running almost as a daemon
with init as the parent. */
setsid();
/* Now the child is completely detached from the original
parent */
/* ... daemon code here ... */
exit(0);
}
/* parent code here */
-- Steve
Thanks for the reply!
Well this seems straight-forward enough, but it doesn't seem to work for
me.. see if I have everything straight..
#include <unistd.h>
#include <stdio.h>
int main()
{
if(fork())
{ /* parent */
sleep(15);
}
else
{ /* child */
printf("setpgrp returned: %d\n",setpgrp());
sleep(5);
}
}
I run the program.. setpgrp is returning zero.. then I quickly look at
the ps listing.. the child's pid is still the parent's, but that may be
okay.. Then after 5 seconds when the child exits.. I do the ps again
and I do still see that the child is now defunct.. the desired effect is
that the child would go away because I don't care what the exit status
was. I was thinking that if init could become the parent of the newly
forked child, then it would clean it up when it exits.
Any ideas?
-- Davy
[email protected] wrote:
>Davy,
>After you fork the process, use setpgrp() to make the process the head of
>it's own process group.
>check man -S2 setpgrp for details.
>
>
>
>Hi, I'm not sure if there's a posix way of doing this, but wanted to
>check if there is a way in linux.
>
>I want to have a daemon that fork/execs a new process, but don't want
>(for various reasons) the responsibility for cleaning up those process
>with the wait() function family. I'm assuming that if the init process
>became the parent of one of these forked processes, then it would clean
>them up for me (is this assumption true?). Besides the daemon process
>exiting, is there a way to disown the process on purpose so that init
>inherits it?
>
>Thanks,
> Davy
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
On Fri, 27 May 2005, Davy Durham wrote:
> Hi, I'm not sure if there's a posix way of doing this, but wanted to check
> if there is a way in linux.
>
> I want to have a daemon that fork/execs a new process, but don't want (for
> various reasons) the responsibility for cleaning up those process with the
> wait() function family. I'm assuming that if the init process became the
> parent of one of these forked processes, then it would clean them up for me
> (is this assumption true?). Besides the daemon process exiting, is there a
> way to disown the process on purpose so that init inherits it?
>
> Thanks,
> Davy
>
Sounds like a job for the Richard Stevens "Advanced Programming in the
UNIX Environment" book. Check out chapter 13, "daemon processes". It
explains the subtleties of process groups, signals, inheritance, etc..
better than most.
-Scott-
Cool.. I looked at the daemon function and I might be able to use it..
However, I compiled your code... seems to work.. but where is the wait()
done on the middle parrent so that it isn't left defunct?
Steven Rostedt wrote:
>Try man daemon.
>
>The way I use to do it was simply do a double fork. That is
>(simplified)...
>
>if ((pid = fork()) < 0) {
> perror("fork");
>} else if (!pid) {
> /* child */
> if ((pid = fork()) < 0) {
> perror("child fork");
> exit(-1);
> } if (pid) {
> /* child parent */
> /* Here we detach from the child */
> exit(0);
> }
> /* Now this code is a child running almost as a daemon
> with init as the parent. */
> setsid();
> /* Now the child is completely detached from the original
> parent */
> /* ... daemon code here ... */
> exit(0);
>}
>
>/* parent code here */
>
>-- Steve
>
>
>
On Fri, 2005-05-27 at 13:55 -0500, Davy Durham wrote:
> Cool.. I looked at the daemon function and I might be able to use it..
>
> However, I compiled your code... seems to work.. but where is the wait()
> done on the middle parrent so that it isn't left defunct?
Sorry, forgot about that...
[...]
> >
> >/* parent code here */
waitpid(pid,&status,0);
/* and then you can look at WEXITSTATUS(status) to
see if the second fork succeeded. */
if (WEXITSTATUS(status)) {
/* failed */
} else {
/* succeeded */
}
/* Here the second child and parent are now divorced */
-- Steve
Davy Durham wrote:
> Cool.. I looked at the daemon function and I might be able to use it..
>
> However, I compiled your code... seems to work.. but where is the
> wait() done on the middle parrent so that it isn't left defunct?
>
I added "waitpid(pid,NULL,0);" after the outer-most if.. which is where
the grand parent cleans up the pid of the intermediate parent.
However, now trying the daemon() function.. which seems to work the
same way.. it definately leaves a pid around.. so I guess you really
need to do a wait() in the parent after forking.. however you don't know
exactly which pid to wait for so you might be reaping some other child
you've previously spawned..
So, for now I'm going to stick with the explicit double fork code.
Thanks!
> Steven Rostedt wrote:
>
>> Try man daemon.
>>
>> The way I use to do it was simply do a double fork. That is
>> (simplified)...
>>
>> if ((pid = fork()) < 0) {
>> perror("fork");
>> } else if (!pid) {
>> /* child */
>> if ((pid = fork()) < 0) {
>> perror("child fork");
>> exit(-1);
>> } if (pid) {
>> /* child parent */
>> /* Here we detach from the child */
>> exit(0);
>> }
>> /* Now this code is a child running almost as a daemon
>> with init as the parent. */
>> setsid();
>> /* Now the child is completely detached from the original
>> parent */
>> /* ... daemon code here ... */
>> exit(0);
>> }
>>
>> /* parent code here */
>>
>> -- Steve
>>
>>
>>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, 2005-05-27 at 14:05 -0500, Davy Durham wrote:
> Davy Durham wrote:
> I added "waitpid(pid,NULL,0);" after the outer-most if.. which is where
> the grand parent cleans up the pid of the intermediate parent.
That's correct.
>
> However, now trying the daemon() function.. which seems to work the
> same way.. it definately leaves a pid around.. so I guess you really
> need to do a wait() in the parent after forking.. however you don't know
> exactly which pid to wait for so you might be reaping some other child
> you've previously spawned..
The daemon function is really just the inner fork and setsid. So with
using the daemon function it looks like this:
if ((pid = fork()) < 0) {
perror("fork");
} else if (!pid) {
if (daemon(0,0) < 0) {
exit(-1);
}
/* daemon code here */
exit(0);
}
waitpid(pid,NULL,0);
-- Steve
On Fri, 2005-05-27 at 14:54 -0400, J. Scott Kasten wrote:
>
> Sounds like a job for the Richard Stevens "Advanced Programming in the
> UNIX Environment" book. Check out chapter 13, "daemon processes". It
> explains the subtleties of process groups, signals, inheritance, etc..
> better than most.
Definitely a good read. God rest his soul. But it doesn't let you know
that there's already a daemon function out there. But what daemon does
is pretty much a complete version of Stevens' example Program 13.1
"daemon_init".
Davy, I recommend that if you don't already have that book, get it.
-- Steve
On Gwe, 2005-05-27 at 19:55, Davy Durham wrote:
> Cool.. I looked at the daemon function and I might be able to use it..
Using daemon() is generally wise - it is basically a double fork and
then one exits so that the orphan child becomes owned by init. However
it also knows about platform specific considerations like setpgrp v
setsid, whether an ioctl must be done to disown the controlling tty etc
which can be fairly OS generation specific.
Alan Cox wrote:
>On Gwe, 2005-05-27 at 19:55, Davy Durham wrote:
>
>
>>Cool.. I looked at the daemon function and I might be able to use it..
>>
>>
>
>Using daemon() is generally wise - it is basically a double fork and
>then one exits so that the orphan child becomes owned by init. However
>it also knows about platform specific considerations like setpgrp v
>setsid, whether an ioctl must be done to disown the controlling tty etc
>which can be fairly OS generation specific.
>
>
Well, when I tried using it in a program with some sleeps to test.. I
noticed that the intermediate process that daemon creates is not cleaned
up with a wait() call (so I see a defunct process in the ps listing).
If I manually do the double fork() then I can call waitpid() myself for
the pid that I know it spawned. But if I just call wait() after
calling daemon, then I don't know if I just cleaned up the pid it
spawned (do I?), or some other previously spawned one (for perhaps
totally different reasons)..
For my specifics it may not be a problem, but I guess I'm just whining
about the fact that daemon() doesn't clean it up itself (or can it?)
Thanks much,
Davy
On Fri, 2005-05-27 at 18:34 -0500, Davy Durham wrote:
> Well, when I tried using it in a program with some sleeps to test.. I
> noticed that the intermediate process that daemon creates is not cleaned
> up with a wait() call (so I see a defunct process in the ps listing).
You didn't use it right. See below.
>
> If I manually do the double fork() then I can call waitpid() myself for
> the pid that I know it spawned. But if I just call wait() after
> calling daemon, then I don't know if I just cleaned up the pid it
> spawned (do I?), or some other previously spawned one (for perhaps
> totally different reasons)..
You still need to fork the first child, and the daemon does the second
fork and exits the parent, and does all the necessary things for the
system to make a proper daemon.
>
> For my specifics it may not be a problem, but I guess I'm just whining
> about the fact that daemon() doesn't clean it up itself (or can it?)
Attached is a simple C program that uses daemon the way you want to.
-- Steve
On Fri, 2005-05-27 at 21:38 -0400, Steven Rostedt wrote:
> } else if (!pid) {
> if (daemon(1,1) < 0) {
> perror("daemon");
> exit(-1);
> }
You probably want to use daemon(0,0), I was just playing with this, and
forgot to put it back. See man daemon for details.
-- Steve
Ok, that's cool.. and it makes sense too..
Thanks
Steven Rostedt wrote:
>On Fri, 2005-05-27 at 21:38 -0400, Steven Rostedt wrote:
>
>
>> } else if (!pid) {
>> if (daemon(1,1) < 0) {
>> perror("daemon");
>> exit(-1);
>> }
>>
>>
>
>You probably want to use daemon(0,0), I was just playing with this, and
>forgot to put it back. See man daemon for details.
>
>-- Steve
>
>
>