> Hi again, > > Ok ... so with some research and playi^H^H^H^H^Htesting I've found the > answer to what's really been bothering me. If I fork(), I get the PID > of the resulting child. However, if THAT child runs and external > command, how do I get the (now grand)child's PID. The answer I was > looking for was a deeper understanding of exec(). >
Yep. Playing is the best way to go. > by fork()ing a child and having that child run exec(), the exec()ed > command will have the SAME process ID as the original child. In > actuality, the exec()ed command is NOT a grandchild, but has taken > over the original child's process and all it's environment (STDIN, > STDOUT, %ENV, etc.). That's what I needed to know! Now, if I just > collect and keep the child's PID, when I run the exec() I'll have the > PID of whatever command was exec()ed. > Correct. > Also, with some experimenting, the setsid() doesn't NEED the original > parent to die to work, it just needs the child to be forked before it > runs setsid(). In other words, if you try to run setsid() BEFORE you > fork the child (in an attempt to give both the child and the parent > the same session and group ID, perhaps) it will fail. If you instead > have the child run setsid() after it is fork()ed, it will run fine, > whether the parent is dead or not! YAY!! > Yep again, making the child a session leader doesn't mean that the parent must go away, more that if it wants to it can. Which is a subtle but important distinction. > > On Thu, 23 Sep 2004 13:30:08 -0600, Wiggins d Anconia > <[EMAIL PROTECTED]> wrote: > > > > > > > On Thu, 23 Sep 2004 11:23:16 -0500, Errin Larsen > > <[EMAIL PROTECTED]> wrote: > > > > Hi perl-people, > > > > > > <<SNIP>> > > > > > > > So, my question is, how do I implement this code WITHOUT the parent > > > > process dieing? > > > > > > > > --Errin > > > > > > > > > <<SNIP>> > > Thanks for the help, Wiggins. I agree this would all be easier if I > just went a grabbed a module, but for (probably strange) reasons I'd > rather not go into, I want to do this from scratch. Also, this has > been extremely helpful in teaching me what's going on with the > backticks, system(), fork() and exec() functions. This process has > really helped me along with my Perl education. > Definitely. You are essentially taking the same path through the madness that I did 2 years ago or so, first attempting to understand the reasons and lowlevels, reading lots of docs and making lots of mistakes. Once I figured it out I was very glad because of the amount I learned, but then opted for the module mostly to prevent code maintenance, hassles, etc. We already had roughly 40 other dependencies, and considering it was probably the easiest to install I wasn't concerned about Just Another Module (hmph, JAM, that works pretty well in the glue analogy ;-)). > Also, I realized that the ORIGINAL parent needs to die (So as to > disassociate the daemons from the calling terminal/process), but I was > looking for a daemon that would run, start other servers, and that > hang around monitoring them. I think we're talking about the same > thing here, just I didn't explain it will originally. > > Now, I just need to implement some code to dump a file with PIDs into > /var/run! Thanks for the suggestions/help and I'll get working on it > now! > Agreed and yep. > --Errin > http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
