cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:

Hey peeps,

I'm running a bunch of stuff now under mod_perl, and need to expand on it to add a few cron jobs that run at various times, from every 5 minutes, to once a month. I have a lovely module used by my existing scripts that only runs under mod_perl. And I want to use it in the cron'd scripts.

I can set up the scripts under a locked down directory and call locally with wget to run them, but this seems a little silly.

So, after all this waffle, I think the question boils down to:

"What's the best way to run scripts under mod_perl from a cron job?"

I'm not sure where to start on this one. A quick search on Google returned lots of fluff...

thoughts?

cLive ;-)

Replies are listed 'Best First'.
Re: Cron Jobs and mod_perl...
by chromatic (Archbishop) on Dec 14, 2002 at 07:07 UTC

    The time you'll spend trying to get mod_perl to run properly under cron is likely more than you'll spend decoupling the bits that don't need mod_perl. The best way to get your job done is to fix your code now. You'll never have a better chance.

Re: Cron Jobs and mod_perl...
by PodMaster (Abbot) on Dec 14, 2002 at 01:20 UTC
    I cannot wrap my brain around this, why do you need to run it under mod_perl?

    You're best solution would be to port whatever is mod_perl dependent and make it not so (you crazy).

    On the other hand, why is it mod_perl dependent? (what portion of the mod_perl functionality is it exploiting)

    Can you take advantage of Apache::FakeRequest?

    I seriously see a conflict of interest here. Whatever part of your mod_perl script that you need to run from cron should be extracted into its own package.

    Anyway, that's just my shot in the dark, later


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      "why do you need to run it under mod_perl?"

      Laziness.

      I'd rather keep one module going than split it into two.

      I guess I'll just eval the use statements for Apache and Apache::DBI, and rewrite my DB subroutines (lazily written because Apache:DBI takes over connect and disconnect methods - long story....).

      Unless anyone has a better idea?

      .02

      cLive ;-)

        I always thought that Apache::DBI overloaded the DBI::connect and DBI::disconnect functions to enable persistent connections under mod-perl and did not really change anything how you programmed the DBI-interface. So if you drop all reference to Apache::DBI and use the correct DBI/DBD combo the program should keepon working.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: Cron Jobs and mod_perl...
by perrin (Chancellor) on Dec 14, 2002 at 18:47 UTC
    I agree with other posters that removing the mod_perl dependencies is a good idea, but honestly it is trivial to trigger a mod_perl handler from cron. Use wget or LWP and your work is done. I've done that many times for jobs that benefit from running inside a daemon because they have a large startup cost.