Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Perl Daemons

by paulbort (Hermit)
on Jul 28, 2004 at 18:04 UTC ( #378138=note: print w/replies, xml ) Need Help??


in reply to Perl Daemons

Don't worry about making programs run forever; worry about people who think that servers run forever. The same memory leaks and stealth bugs that might be in your Perl might also be in the server OS.

I don't trust a server with more than about 30 days of uptime. In fact, the Big Brother server monitoring software includes code to send an alarm if server uptime exceeds user-defined threshholds.

Worry about making the code solid for a 30-90 day run. Any longer than that and you could run into problems with the parts you didn't write.

The worker child suggestion above is also a very good idea.

--
Spring: Forces, Coiled Again!

Replies are listed 'Best First'.
Re^2: Perl Daemons
by RolandHalder (Novice) on Jul 28, 2004 at 19:15 UTC
    Maybe one should use another server monitoring software ;.)

    At my company we are using mon, a fantastic peace of software to monitor more than fifty devices.

    Mon is a perl script (sic!) and the last time I bootet the server was January 1 this year, because we had to take away the power of the whole server room. Before that the server was running for more than 400 days and mon.pl is only being restartet when there are any config changes - I think I should even be able to reload the config with a SIG HUP, but didn't test it already.

    The server is running SuSE Linux 8.0 with a 2.4 kernel.

    Therefore I do not see any reason to restart a good written piece of perl daemon software just to avoid any potential trouble!

    Cheers Roland

      I'm sure that the OP can use care and write a solid, non-leaking daemon that would run for years. I did not mean to disparage OP's daemon, coding, or any monitoring software.

      I did mean that there are millions of lines of very clever code holding up that daemon, and it is impractical to test that code for months of constant operation. So as a precaution, monthly server restarts will do two things:
      1. Prevent any long-term leakage problems from rearing their ugly heads
      2. Catch any configuration changes that might have been made in the preceding month that would prevent the server from returning to normal operation. A failed restart at the beginning of a maintenance window is much easier to deal with than a failed restart after a move or extended power outage.

      --
      Spring: Forces, Coiled Again!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://378138]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2019-07-18 11:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?