Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: A perl daemon

by trm (Novice)
on Jan 20, 2009 at 19:00 UTC ( [id://737643]=note: print w/replies, xml ) Need Help??


in reply to Re: A perl daemon
in thread A perl daemon

I found this code potentially very handy. However, I found that the dispatcher function within the class is a new process every time it executes. So if I update the cron, the changes are lost once the function completes.

If I create something similar as a script (not as a daemon), the schedule doesn't fork off a new process each time the function is called.

Is there a way to mimic this functionality (non-forking) by using a daemon similar to the above example?

Replies are listed 'Best First'.
Re^2: A perl daemon
by clinton (Priest) on Jan 20, 2009 at 20:14 UTC
    However, I found that the dispatcher function within the class is a new process every time it executes. So if I update the cron, the changes are lost once the function completes.

    You mean, if you were to update the cron table from one of the jobs? Yes, those changes would be lost.

    I've been using the example code above in production for 2 years now, and it runs beautifully. I have a large application, which gets loaded at startup, and using fork to launch each process on linux is really cheap (as it makes use of Copy on Write). It also means that different jobs can run simultaneously.

    In Schedule::Cron there is an option nofork, which (not surprisingly) launches the jobs without forking :) - this would let you alter your cron table, but would only run jobs sequentially.

    Instead of that, you could consider making your daemon re-read the cron table whenever it receives a signal of your choosing, eg $SIG{USR}, then your child job could update the cron table, and signal its parent.

      Thank you for your response.

      I just need "something" to update the cron. I was thinking that I could get the parent to update the cron in a while loop, but it looks like after I "run" the schedule, the schedule seems to have control - i.e. until it completes, the next lines in what you called "init_cron_daemon" won't execute.

      Perhaps I just need the schedule to signal the parent to update the cron. I just need to research how I signal that parent.

      The only thing preventing me from using this is updating the cron on the fly. I found that deleting crons caused table problems, but I wrote workarounds for that. Now I need to avoid the forking - or precisely as you state, work around it somehow.

        For handling signals, have a look at perlipc, especially the section entitled Handling the SIGHUP Signal in Daemons.

        You probably want something like this (untested):

        sub reload_cron { my $cron = shift; my $file = shift; $cron->clean_timetable; $cron->load_crontab($file); } { local $SIG{USR1} = sub { reload_cron($cron,$file) }; $cron->run; }
        Then to signal the cron daemon, you need it's PID, and you can do:
        kill $pid,10; # SIGUSR1

        Hope this helps>

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2024-03-28 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found