Unix Programming - Daemon question

Author

Daemon question

K-mart Cashier

2007-10-14, 7:18 pm

Given the following:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include "ourhdr.h"

int
daemon_init(void)
{
pid_t pid;

if ( (pid = fork()) < 0)
return(-1);
else if (pid != 0)
exit(0); /* parent goes bye-bye */

/* child continues */
setsid(); /* become session leader */

chdir("/"); /* change working directory */

umask(0); /* clear our file mode creation mask
*/

return(0);
}

In this case, how do we know for sure that parent, and not the child,
terminates first? I was under the impression that when you forked,
there was no guaranteed synchronization, unless you used something
like wait().

Måns Rullgård

2007-10-14, 7:18 pm

K-mart Cashier <cdalten@gmail.com> writes:

> Given the following:
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include "ourhdr.h"
>
> int
> daemon_init(void)
> {
> pid_t pid;
>
> if ( (pid = fork()) < 0)
> return(-1);
> else if (pid != 0)
> exit(0); /* parent goes bye-bye */

This should be _exit(0) (POSIX) or _Exit(0) (C99, equivalent to
_exit() in POSIX). Calling exit() will do things you probably don't
want here, such as flush open stdio file handles

> /* child continues */
> setsid(); /* become session leader */
>
> chdir("/"); /* change working directory */
>
> umask(0); /* clear our file mode creation mask */
>
> return(0);
> }
>
> In this case, how do we know for sure that parent, and not the child,
> terminates first?

There is no such guarantee.

> I was under the impression that when you forked, there was no
> guaranteed synchronization, unless you used something like wait().

That is correct. What makes you believe special rules would apply
here? Why would it matter which process terminates first?

--
Måns Rullgård
mans@mansr.com

K-mart Cashier

2007-10-14, 7:18 pm

On Oct 14, 1:24 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> K-mart Cashier <cdal...@gmail.com> writes:
>
>
>
>
> This should be _exit(0) (POSIX) or _Exit(0) (C99, equivalent to
> _exit() in POSIX). Calling exit() will do things you probably don't
> want here, such as flush open stdio file handles
>
>
>
>
>
>
> There is no such guarantee.
>
>
> That is correct. What makes you believe special rules would apply
> here? Why would it matter which process terminates first?
>
> --
> M=E5ns Rullg=E5rd
> m...@mansr.com

I thought that it mattered which process would terminate first when
coding a daemon. Am I wrong?

Måns Rullgård

2007-10-14, 7:18 pm

K-mart Cashier <cdalten@gmail.com> writes:

> On Oct 14, 1:24 pm, Måns Rullgård <m...@mansr.com> wrote:
>
> I thought that it mattered which process would terminate first when
> coding a daemon. Am I wrong?

A daemon is nothing but a process without a controlling tty. Why
would there be any special rules for them?

--
Måns Rullgård
mans@mansr.com

K-mart Cashier

2007-10-14, 7:18 pm

On Oct 14, 1:41 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> K-mart Cashier <cdal...@gmail.com> writes:
>
>
>
>
>
>
>
> A daemon is nothing but a process without a controlling tty. Why
> would there be any special rules for them?
>
> --
> M=E5ns Rullg=E5rd
> m...@mansr.com

Bear with this. My reading comprehension sort of sucks butt. This is
probably why I still work an $8.00/hr. job...

And I quote part of page 425 from "Advanced programming in the Unix
Environment" by Stevens and Rago

"2. Call fork and have the parent exit. This does several things.
First, if the daemon was started as a simple shell command, having the
parent terminate makes the shell think that the command is done.
Second, the child inherits the process group ID of the parent but gets
a new process ID, so we're guaranteed that the child is not a process
group leader. This is a prerequisite for the call to setsid that is
done next."

When I read this paragraph, I thought that this implied that one had
to go before the other. Ie, that the order of the parent and child
somehow mattered.

Måns Rullgård

2007-10-14, 7:18 pm

K-mart Cashier <cdalten@gmail.com> writes:

> On Oct 14, 1:41 pm, Måns Rullgård <m...@mansr.com> wrote:
>
> Bear with this. My reading comprehension sort of sucks butt. This is
> probably why I still work an $8.00/hr. job...
>
> And I quote part of page 425 from "Advanced programming in the Unix
> Environment" by Stevens and Rago
>
> "2. Call fork and have the parent exit. This does several things.
> First, if the daemon was started as a simple shell command, having the
> parent terminate makes the shell think that the command is done.
> Second, the child inherits the process group ID of the parent but gets
> a new process ID, so we're guaranteed that the child is not a process
> group leader. This is a prerequisite for the call to setsid that is
> done next."
>
> When I read this paragraph, I thought that this implied that one had
> to go before the other. Ie, that the order of the parent and child
> somehow mattered.

That paragraph is talking about two fairly independent effects of the
fork/exit combination. When the shell runs a command, it calls fork()
and exec() to launch the command, while the shell process wait()s for
the forked process to finish. When your daemon forks and has the
original process exit, the shell assumes the command has finished and
resumes reading user commands. This is the main reason for calling
fork() in the daemon. Independently of this, we want the daemon to be
a process group leader, which we accomplish by calling setsid(). This
call succeeds only if the process is not already a group leader, and
the prior fork() ensures that this cannot be the case. The setsid()
call is not dependent on the parent process having terminated.

--
Måns Rullgård
mans@mansr.com

Almond

2007-10-15, 1:27 am

In article <1192391756.902540.232880@i13g2000prf.googlegroups.com>, K-mart Cashier <cdalten@gmail.com> wrote:
>Given the following:
>
>#include <sys/types.h>
>#include <sys/stat.h>
>#include <fcntl.h>
>#include "ourhdr.h"
>
>int
>daemon_init(void)
>{
> pid_t pid;
>
> if ( (pid = fork()) < 0)
> return(-1);
> else if (pid != 0)
> exit(0); /* parent goes bye-bye */
>
> /* child continues */
> setsid(); /* become session leader */
>
> chdir("/"); /* change working directory */
>
> umask(0); /* clear our file mode creation mask
>*/
>
> return(0);
>}
>
>
>In this case, how do we know for sure that parent, and not the child,
>terminates first? I was under the impression that when you forked,
>there was no guaranteed synchronization,

Yep, they are independent processes.
You have to synchronize yourself.
A tricky business. I had similar issue and wasted days
on trying to synchronize, until I finally gave up and
a different idea appeared out of nowhere, where I could
just forget about trying to syncrhonize things. There
were so many places to synchronize that it wasn't even
clear there is gain to run multiple processes.

>unless you used something
>like wait().
>

--
Get yourself the most powerful tool for usenet you ever heard of.

Version 4.0.1 Hail Democracy Release has been released.

Important feature additions and various improvements
and optimizations.

Web page:

http://newsmaestro.sourceforge.net/
or
http://tarkus01.by.ru/

NewsMaestro download page:

http://newsmaestro.sourceforge.net/...Information.htm

Almond

2007-10-15, 1:27 am

In article <yw1xk5ppjvh5.fsf@thrashbarg.mansr.com>, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com> wrote:
>K-mart Cashier <cdalten@gmail.com> writes:
>
>
>This should be _exit(0) (POSIX) or _Exit(0) (C99, equivalent to
>_exit() in POSIX). Calling exit() will do things you probably don't
>want here, such as flush open stdio file handles

Oh, you again?
Yep. That is what i ment when I said:
You don't have anything of value to say, or do you?

You see, just about the last thing he needs
is your lecure on posix on how to properly return
the exit status.

Smart, I tellya.
Anything else?
Lemme see here.

>
>There is no such guarantee.

Oh, finally.
True.

>
>That is correct. What makes you believe special rules would apply
>here? Why would it matter which process terminates first?

:--}

Is this a joke?

Why, why, why.

SURE it does matter.
Because it is a complex synchronization issue.
If you have access to the same resource and have
multiple processes/threads operating on it, then
it does matter to the main thread and to other threads.
Because, once one of them terminates, it may request
a different resource, which may cause havoc.

Simple enough?

Or you want me to chew more on this?

--
Get yourself the most powerful tool for usenet you ever heard of.

Version 4.0.1 Hail Democracy Release has been released.

Important feature additions and various improvements
and optimizations.

Web page:

http://newsmaestro.sourceforge.net/
or
http://tarkus01.by.ru/

NewsMaestro download page:

http://newsmaestro.sourceforge.net/...Information.htm

Rainer Weikusat

2007-10-15, 1:25 pm

J de Boyne Pollard <j.deboynepollard@tesco.net> writes:
> KC> And I quote part of page 425 from "Advanced programming in the
> Unix
> KC> Environment" by Stevens and Rago
> KC>
> KC> "2. Call fork and have the parent exit. This does several things.
> KC> First, if the daemon was started as a simple shell command, having
> the
> KC> parent terminate makes the shell think that the command is done.
>
> That's bad advice. Ignore that part of that book.
>
> <URL:http://homepages.tesco.net./~J.deBo...GA/unix-daemon-
> design-mistakes-to-avoid.html>

Thanks for clarifiying your relation to D. Bernstein. I am still a
little bit weak at autodetection it.

Almond

2007-10-16, 1:28 am

In article <1192449864.779700.261550@v23g2000prn.googlegroups.com>, J de Boyne Pollard <j.deboynepollard@tesco.net> wrote:
>KC> And I quote part of page 425 from "Advanced programming in the
>Unix
>KC> Environment" by Stevens and Rago
>KC>
>KC> "2. Call fork and have the parent exit. This does several things.
>KC> First, if the daemon was started as a simple shell command, having
>the
>KC> parent terminate makes the shell think that the command is done.
>
>That's bad advice. Ignore that part of that book.

Yep.

><URL:http://homepages.tesco.net./~J.deBo...GA/unix-daemon-
>design-mistakes-to-avoid.html>
>

--
Get yourself the most powerful tool for usenet you ever heard of.

NewsMaestro v. 4.0.1 Hail Democracy Release has been released.

Important feature additions and various improvements
and optimizations.

Web page:

http://newsmaestro.sourceforge.net/

NewsMaestro download page:

http://newsmaestro.sourceforge.net/...Information.htm

J de Boyne Pollard

2007-10-24, 1:33 pm

KC> And I quote part of page 425 from "Advanced programming in
KC> the Unix Environment" by Stevens and Rago
KC>
KC> "2. Call fork and have the parent exit. This does several things.
KC> First, if the daemon was started as a simple shell command,
KC> having the parent terminate makes the shell think that the
KC> command is done.

JdeBP> That's bad advice. Ignore that part of that book.
JdeBP>
JdeBP> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/unix-
daemon-design-mistakes-to-avoid.html>

RW> Thanks for clarifiying your relation to D. Bernstein. I am still a
RW> little bit weak at autodetection it.

Actually, where you are weak is logic. Bernstein's softwares are
mentioned on the page, but then so too are softwares by Sun
Microsystems, Gerrit Pape, Scott James Remnant, and IBM. One cannot
logically draw any inferences, let alone clarifications, from the fact
that pieces of software are mentioned. (It's saddening to see yet
again that a lack of anything to say on the actual technical subject
at hand results in the use of distraction to attempt to get the
discussion away from the technical topic and onto something else
instead.) One cannot, of course, logically conclude that I am related
to Bernstein any more than one can logically conclude that IBM is
related to Bernstein because it, too, gives the advice that forking in
a Unix daemon in order to "put it into the background" is "a
mistake". I recommend pausing to think that perhaps all of these
people have come to the same designs and the same conclusions
independently over a period of more than a decade, because they are
the correct ones to come to.