How to Write a Proper Daemon

c4onastick has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I've got a Counter-Strike server that I run (all work and no play is no fun at all!) I have a great piece of perl code that parses the logs and fills a database full of stats (very cool. Psychostats by Stormtrooper). Problem is, usually you just set up a cron job to run the script every 10 minutes or so, but I'm not running the server continuously. I'd like to write a little script, daemon really, that'll check and see if the CS server is up periodically and run the stats script if it is.

What's the proper way to write a daemon? Using Proc::Daemon, one can spawn the daemon process, but what about the meat of the program?

I was considering using something like this:

while(1){
  ... #do stuff here
  sleep 5;
}
[download]

Is there a better/cleaner way? Thanks!

Comment on How to Write a Proper Daemon Download Code

Replies are listed 'Best First'.
Re: How to Write a Proper Daemon by Old_Gray_Bear (Bishop) on Apr 22, 2007 at 22:20 UTC
Take a look at the Perl Cookbook, chapter 17. Recipes 17.15 and 17.16 will give you pointers on Daemons, Uses and Pitfalls there of. Recipes 17.11 (Forking Servers), 17.12 (Pre-Forking Severs), and 17.13 (Non-Forking Servers) are also useful, discussing the various ways the communications can be set up between the Server and the Servee. ---- I Go Back to Sleep, Now. OGB	[reply]
Re: How to Write a Proper Daemon by shigetsu (Hermit) on Apr 22, 2007 at 22:16 UTC
This kind of question has been previously excellently answered by Grandfather in Re: A perl daemon. Super Search is your friend & helpful in extracting results from previous nodes provided specific keywords.	[reply]
Re^2: How to Write a Proper Daemon by c4onastick (Friar) on Apr 22, 2007 at 22:23 UTC
Ah. Thank you. The simple search didn't yield any (meaningful) results. I may have been too hasty in my post.	[reply]
Re: How to Write a Proper Daemon by Fletch (Bishop) on Apr 22, 2007 at 23:12 UTC
Your question aside, you might want to rethink this. Unless there's substantial overhead that you avoid by running a persistent process (say there's some startup cost to computing the existing statistics state that you want to keep updated), what exactly do you think moving away from a cron'd solution is gaining you? You could always just have the cron'd code check for the server at the same interval and just exit if the CS server's not runnng. You get the same benefit (the stats aren't run unless the server's up) and less work (cron just works and is something you don't have to maintain).	[reply]