Depends on what you want. Net::Server::Daemonize gives you lots of tools for POSIX systems to give you a full blown daemon process. In Unix you could also "daemonize" any process simply by typing:

nohup <your script here> &
[download]

Works for running my copy of Amphetadesk.

HTH

My biggest question is how do you get the program to detach from the terminal?

Use ioctl() or POSIX::setsid() and re-open your file descriptors.

If you really want to daemonize your process, you might also want to chroot, change your working directory to '/', and change your umask.

Proc::Daemon will do most of that for you, but if you want to chroot() you'll have to do that yourself, I think.

-sauoq
"My two cents aren't worth a dime.";

Heh, a couple different reasons:

• I learned a ton about many aspects of Perl from this book, and found it easy to understand (perldoc is not always easy to understand :)
• I have enjoyed other of the same authors books and modules, and supporting his efforts might keep him writing :)
• The book actually has a daemon module (several actually) and walks you through different revs of the module as features are added, as well as showing More Than One Way To Do It. This encompasses not only what perldoc does, but gives a great understanding on how to fit all the pieces together.
  
  While I agree that perldoc can answer many questions, and I don't want to belittle it as a resource in any way, the original poster seemed to be new to the topic in general, and the book would provide a clear picture of what they were dealing with, all in one package. With the docs you may be going back and forth to several different topics and possibly missing things, as well the possibility of missing important security concerns rises dramatically without a bit more of a big picture view.
  
  To close I should say that, while books are a great source of information, the concepts should be sanity checked with the documentation. Books may have been using older revs of modules, perl, and OS's. Also, books may have been written before important security issues or other bugs were found, and may not address those issues as well as the docs with your latest distro. Be smart, use all the available reference material you can!
  
  "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Here's a short example:

# do startup/initialization code
...
if (my $pid = fork()) {
    print "Sending to background...\n";
    exit(0);
}
...
# main application code here
[download]

I ++ed your node, but please note that on some systems you'd have to fork() and exit() twice to completely dissociate from the original process's resources. fork(), exit(), and POSIX::setsid() is even better.

Proc::Daemon has its good points, but why would I want it to reopen three file handles if I'm going to turn around and close them anyway? That doesn't seem like a very useful thing to do in the generic case. Still, for production code it wouldn't hurt to use it just for the fact that someone else has already debugged it.

Christopher E. Stith
use coffee;

On Linux, you could just be a slacker and use chkconfig. This buys you process control and integration into WebMin, RedHat's Services Tab, etc, etc. Might as well use the OS tools when they are decent! --Attila (who is not logged in)