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().

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

In article <yw1xk5ppjvh5.fsf@thrashbarg.mansr.com>, examnotes <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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

In article <1192449864.779700.261550@v23g2000prn.googlegroups.com>, J de Boyne Pollard <j.de
boynepollard@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

[ Post a follow-up to this message ]