Daemon question - Unix

This is a discussion on Daemon question - Unix ; Given the following: #include #include #include #include "ourhdr.h" int daemon_init(void) { pid_t pid; if ( (pid = fork()) return(-1); else if (pid != 0) exit(0); /* parent goes bye-bye */ /* child continues */ setsid(); /* become session leader */ ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Daemon question

  1. Daemon question

    Given the following:

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


  2. Re: Daemon question

    K-mart Cashier writes:

    > Given the following:
    >
    > #include
    > #include
    > #include
    > #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

  3. Re: Daemon question

    On Oct 14, 1:24 pm, Måns Rullgård wrote:
    > K-mart Cashier writes:
    > > Given the following:

    >
    > > #include
    > > #include
    > > #include
    > > #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
    > m...@mansr.com



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


  4. Re: Daemon question

    K-mart Cashier writes:

    > On Oct 14, 1:24 pm, Måns Rullgård wrote:
    >> K-mart Cashier writes:
    >>
    >>> [fork(); setsid();]

    >>
    >> > 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?

    >
    > 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

  5. Re: Daemon question

    On Oct 14, 1:41 pm, Måns Rullgård wrote:
    > K-mart Cashier writes:
    > > On Oct 14, 1:24 pm, Måns Rullgård wrote:
    > >> K-mart Cashier writes:

    >
    > >>> [fork(); setsid();]

    >
    > >> > 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?

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


  6. Re: Daemon question

    K-mart Cashier writes:

    > On Oct 14, 1:41 pm, Måns Rullgård wrote:
    >> K-mart Cashier writes:
    >> > On Oct 14, 1:24 pm, Måns Rullgård wrote:
    >> >> K-mart Cashier writes:

    >>
    >> >>> [fork(); setsid();]

    >>
    >> >> > 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?

    >>
    >> > 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?

    >
    > 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

  7. Re: Daemon question

    In article <1192391756.902540.232880@i13g2000prf.googlegroups. com>, K-mart Cashier wrote:
    >Given the following:
    >
    >#include
    >#include
    >#include
    >#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/D...nformation.htm


  8. Re: Daemon question

    In article , =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= wrote:
    >K-mart Cashier writes:
    >
    >> Given the following:
    >>
    >> #include
    >> #include
    >> #include
    >> #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


    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.

    >> /* 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.


    Oh, finally.
    True.

    >> 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?


    :--}

    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/D...nformation.htm


  9. Daemon question

    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.

    http://homepages.tesco.net./~J.deBoy...A/unix-daemon-
    design-mistakes-to-avoid.html>


  10. Re: Daemon question

    J de Boyne Pollard 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.
    >
    > http://homepages.tesco.net./~J.deBoy...A/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.

  11. Re: Daemon question

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

    >http://homepages.tesco.net./~J.deBoy...A/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/D...nformation.htm


  12. Re: Daemon question

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


+ Reply to Thread