Ok, since no one wanted to help me with this, I needed to look through some googled stuff to find the answer myself. In the spirit of helping beginers (which of course I am) I'll post what I found! (This material is from page 2 of the tutorial there):
<<quote>> There are several rules or characteristics that most daemons possess. If a daemon does not follow these basic rules, it will most likely become a demon and wreak havoc on your system. Fork and Exit The first thing a daemon should do is fork() a child process and have the parent process exit(). This is necessary for several reasons. First, it disassociates the process from the controlling terminal, or the login shell. Second, it removes the process from the process group that initiated the program. This ensures that the process is not a process group leader, which is required for setsid() to run successfully. Call setsid() setsid() is a POSIX function that turns the process into a session leader, group leader, and ensures that it doesn't have a controlling terminal. Change Working directory The current working directory should be changed with chdir to the root directory (/). This is necessary to avoid using a working directory that resides on a mounted partition. If the process is started on a mounted partition, the system administrator wouldn't be able to unmount the partition until the process was halted. You could, of course, specify a different working directory as long as it doesn't reside on a remotely mounted partition. File Creation Mode The umask determines the default permissions new files are assigned. Setting umask to 0 removes the defaults that might otherwise disable permissions the daemon intended to enable when creating files. Close Unneeded File Handles Besides closing any filehandles that might have been opened, daemons often redirect STDIN to read from, and STDOUT and STDERR to write to /dev/null. open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; open STDOUT, '>/dev/null'; open STDERR, '>/dev/null'; Logging Messages In some cases, you may want to record an error or messages to a log file on the system. This can be accomplished by redirecting STDOUT and STDERR to one or more log files. open STDOUT, ">>$access_log" or die "Can't write to $access_log: $!"; open STDERR, ">>$error_log" or die "Can't write to $error_log: $!"; <</quote>> This material was all found at the following link: http://www.webreference.com/perl/tutorial/9/ and is authored by ... well, here's a cut-n-paste of the about page: About Mother of Perl - Mother of Perl is a free biweekly how-to devoted to all things Perl. Perl has been an integral part of the Web developer's toolkit for years now. There are probably more Perl scripts, tools, and libraries available for Web Development than any other modern language. This column will attempt to address the needs and concerns of the Desparate Perl Hacker© by providing practical, powerful, and elegant solutions to everyday problems in 100 lines of code or less. If you would like to see a topic or problem area covered in Mother of Perl, please let me know by sending me some feedback. The Author - Jonathan Eisenzopf is an author, teacher, and consultant who has worked with companies like Netscape, Chrysler, Mecklermedia, Bell Atlantic, and Litton/PRC to deploy large scale Web-based information systems. He is presently a Principal Software Engineer and VP of Technology at Whirlwind Interactive, based in the Washington D.C. area. Jonathan is active in the Perl and XML communities by delivering presentations to user groups, contributing articles to publications such as The Perl Journal, authoring modules for CPAN, and maintains www.perlxml.com, an information clearinghouse for Perl and XML resources. Jonathan is also a co-author of an upcoming book from O'Reilly and Associates covering Perl and XML. On Tue, 24 Aug 2004 15:59:57 -0500, Errin Larsen <[EMAIL PROTECTED]> wrote: > Hi, > > Can you help me understand the below a little better. > > As I understand what's going on, the Process (let's say PID=100) > spawns a child with the fork() function (let's say PID=200). This > (200) is assigned to $pid in the parent, and zero (0) is assigned to > $pid in the child. So, what does "my $pid=fork()" resolve to in each > case? I'll assume that it resolves to the PID that fork returns. So, > in the parent, the statement resolves to 200 and the unless statement > doesn't resolve. In the child, the statement resolves to 0 and the > unless statement DOES resolve. So, the parent prints a message to > STDOUT and quits, while the child keeps on running (in the little > do/while loop) doing that stuff that's in there :) Ok ... so, um, why > go through all this? Why not just write your do/while block and just > execute it in the background on the command line? is fork() doing > something else that helps a daemon that I'm not aware of? > > --Errin > > On Sat, 21 Aug 2004 09:53:23 -0400, Adam Rosi-Kessel > <[EMAIL PROTECTED]> wrote: > > <<SNIP>> > > > > > Here's the skeleton of it: > > > > ---- > > unless (my $pid = fork()) { > > do { > > &SendEmailToUsers; > > sleep 3 * 24 * 60 * 60; > > } while (1); > > } > > > > print "Starting email daemon...\n"; > > ----- > > > > That's all. This will run indefinitely, and every three days run the > > subroutine SendEmailToUsers. You obviously need to add a lot more to > > <<SNIP>> > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
