This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: modperl@apache.org
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: cron for mod_perl?
Date: Tue, 13 Feb 2001 13:51:14 -0500
Is there a way to have a Perl function called at some point in time,
like I think AOLserver can do in Tcl (but I don't want to do either
AOLserver or Tcl!)?
I thought about checking the time in a PerlCleanupHandler, but this
would be in each Apache subprocess and I want this to get called only
once. The precision is not so important (unless we're talking hours
later or something like that!).
I thought of having a table of jobs in my PostgreSQL database and
(carefully avoiding race conditions with transactions/locking) checking
if the next job was due to be run, but that doesn't "smell" very good. I
could run the query only on the condition that a minute has passed since
the last time we did it, but still, I'm not sure.
I would like to know if anyone already did that or have any idea on how
to do that more properly?
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Matt Sergeant <matt@sergeant.org>
Subject: Re: cron for mod_perl?
Date: Tue, 13 Feb 2001 19:00:15 +0000 (GMT)
On Tue, 13 Feb 2001, Pierre Phaneuf wrote:
>
> Is there a way to have a Perl function called at some point in time,
> like I think AOLserver can do in Tcl (but I don't want to do either
> AOLserver or Tcl!)?
>
> I thought about checking the time in a PerlCleanupHandler, but this
> would be in each Apache subprocess and I want this to get called only
> once. The precision is not so important (unless we're talking hours
> later or something like that!).
>
> I thought of having a table of jobs in my PostgreSQL database and
> (carefully avoiding race conditions with transactions/locking) checking
> if the next job was due to be run, but that doesn't "smell" very good. I
> could run the query only on the condition that a minute has passed since
> the last time we did it, but still, I'm not sure.
>
> I would like to know if anyone already did that or have any idea on how
> to do that more properly?
Pretty much what you've already found out - Apache has no "cron" like
daemon. One way you can do it is fork off a sub-process and run some sort
of Cron perl module (I think there's a Cron module on CPAN, or you can run
cron-like features with POE).
===
To: modperl@apache.org
From: Vivek Khera <khera@kciLink.com>
Subject: Re: cron for mod_perl?
Date: Tue, 13 Feb 2001 14:16:44 -0500
>>>>> "PP" == Pierre Phaneuf <pp@ludusdesign.com> writes:
PP> Is there a way to have a Perl function called at some point in time,
PP> like I think AOLserver can do in Tcl (but I don't want to do either
PP> AOLserver or Tcl!)?
Set up a handler and have a cron job "GET" the URL for it.
You already have the "GET" program from the lwp package while
installing mod_perl.
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Matt Sergeant <matt@sergeant.org>
Subject: Re: cron for mod_perl?
Date: Tue, 13 Feb 2001 22:39:49 +0000 (GMT)
On Tue, 13 Feb 2001, Pierre Phaneuf wrote:
> Matt Sergeant wrote:
>
> > Pretty much what you've already found out - Apache has no "cron" like
> > daemon. One way you can do it is fork off a sub-process and run some sort
> > of Cron perl module (I think there's a Cron module on CPAN, or you can run
> > cron-like features with POE).
>
> Hmm, too bad, that would have been easy to implement in the Apache core
> request processing loop (it's build into the core of AOLserver). I'll
> look to make sure, but I think this will be possible in Apache 2.0.
> Anyway, that doesn't fix my problem for now.
>
> Isn't forking off from Apache rather nasty? I saw something to that
> effect somewhere in the eagle book and on some web pages, but I think
> there are ways to do that without causing problems.
Yes, its a pain. I suggest using the ways detailed below. My only problem
with those ways is that its not controlled from your application
generally, unless you write your own cron-a-like in Perl, and access your
datastore to get the configuration.
> Perrin Harkins wrote:
>
> > The common way to do it is to just use the real cron facility (assuming you
> > are on unix) and have it call a URL on your server using LWP.
>
> I am on a Unix-like system, but I wanted the events to be updated by the
> web server itself, so that I could use the Apache::DBI cached connection
> to the DBMS (I want to store the events in there).
The cached connection will be used, just as it would for the rest of your
application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and
executes faster too. And yes, you can restrict that URL to localhost, or
password protected.
===
To: "modperl@apache.org" <modperl@apache.org>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Tue, 13 Feb 2001 18:32:10 -0500
Matt Sergeant wrote:
> > Isn't forking off from Apache rather nasty? I saw something to that
> > effect somewhere in the eagle book and on some web pages, but I think
> > there are ways to do that without causing problems.
>
> Yes, its a pain. I suggest using the ways detailed below. My only problem
> with those ways is that its not controlled from your application
> generally, unless you write your own cron-a-like in Perl, and access your
> datastore to get the configuration.
Well, if I call the "check for things to do" URI every minute, then I'll
be just fine. Many times, I'll just check and find nothing to do, but
it'll be under "enough" application control. You might contrieve adding
a cron entry as being "outside the application" though...
I would really like putting this in a cleanup handler, but the problem I
see is if I don't get any hit for too long (which might happen for an
internal web site, say over the weekend), I might miss events. I'll
probably have a combination of both approaches...
> > I am on a Unix-like system, but I wanted the events to be updated by the
> > web server itself, so that I could use the Apache::DBI cached connection
> > to the DBMS (I want to store the events in there).
>
> The cached connection will be used, just as it would for the rest of your
> application. Also note that HTTP::GHTTP loads a *lot* faster than LWP, and
> executes faster too. And yes, you can restrict that URL to localhost, or
> password protected.
I was thinking of using wget with "-O /dev/null". :-)
As for the cached database connection, I knew about that, but I was
thinking of the forking approach (where there was no cached connection
available (not that it couldn't be cached!)).
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Perrin Harkins <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Tue, 13 Feb 2001 15:54:49 -0800 (PST)
On Tue, 13 Feb 2001, Pierre Phaneuf wrote:
> Well, if I call the "check for things to do" URI every minute, then I'll
> be just fine. Many times, I'll just check and find nothing to do
Huh? Why would you call it if there's nothing to do? Are you thinking
you'll write a cron-ish task/timing spec for your Perl app and just use
the cron triggers as a constant clock?
===
To: "modperl@apache.org" <modperl@apache.org>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 09:45:01 -0500
Perrin Harkins wrote:
> > Well, if I call the "check for things to do" URI every minute, then I'll
> > be just fine. Many times, I'll just check and find nothing to do
>
> Huh? Why would you call it if there's nothing to do? Are you thinking
> you'll write a cron-ish task/timing spec for your Perl app and just use
> the cron triggers as a constant clock?
Yes, exactly. My plan is to have a table with the tasks in my database,
and check expired tasks in a cleanup handler. I'll have to lock the
table, so that only one process does that. I'll also query the database
only every so often, not at every request cleanup.
The more hits I get, the more accurate the "cron" will be, but I think I
will use a cron trigger a request to have a minimum level of accuracy
(could be every half-hour, just to make sure we're never late by more
than that, or whatever is appropriate).
Anything better?
===
To: "Pierre Phaneuf" <pp@ludusdesign.com>,
<modperl@apache.org>
From: "Perrin Harkins" <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 09:11:05 -0800
> > Huh? Why would you call it if there's nothing to do? Are you thinking
> > you'll write a cron-ish task/timing spec for your Perl app and just use
> > the cron triggers as a constant clock?
>
> Yes, exactly. My plan is to have a table with the tasks in my database,
> and check expired tasks in a cleanup handler. I'll have to lock the
> table, so that only one process does that. I'll also query the database
> only every so often, not at every request cleanup.
>
> The more hits I get, the more accurate the "cron" will be, but I think I
> will use a cron trigger a request to have a minimum level of accuracy
> (could be every half-hour, just to make sure we're never late by more
> than that, or whatever is appropriate).
>
> Anything better?
Well, by frequently hitting your web server and having it look in the
database to decide to do nothing, you're putting a lot of unnecessary stress
on your server. What's wrong with making individual cron jobs that call
individual URLs (think of it as RPC) to cause actions on your web server
exactly when you want them done? Doesn't that sound a whole lot simpler?
- Perrin
===
To: Perrin Harkins <perrin@primenet.com>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 15:45:47 -0500
Perrin Harkins wrote:
> > Yes, exactly. My plan is to have a table with the tasks in my database,
> > and check expired tasks in a cleanup handler. I'll have to lock the
> > table, so that only one process does that. I'll also query the database
> > only every so often, not at every request cleanup.
>
> Well, by frequently hitting your web server and having it look in the
> database to decide to do nothing, you're putting a lot of unnecessary stress
> on your server. What's wrong with making individual cron jobs that call
> individual URLs (think of it as RPC) to cause actions on your web server
> exactly when you want them done? Doesn't that sound a whole lot simpler?
I think you are over-evalutating the stress on my server. With the
speediest time base I was talking about (once per minute cron job), that
would be 1440 HEAD requests per day, each requiring 1 simple database
query that will most probably return no row at all (a query that returns
many rows is slower, because it has to transmit these rows).
Many sites with database-driven pages have multiple complex queries on
some pages and run in the millions of page-views per day.
As for the simplicity, having multiple individual custom cron jobs is
simpler than one single generic cron job?
But still, I don't like my solution very much either. My problem lies in
the case where I get a lot of hits, I want to be careful of what I run
in my cleanup handler (if I hit the database at every cleanup, I'll
start piling up daemons if I get plenty of hits). I was thinking of
having a variable with a timestamp of when we last checked the database,
and getting into a cleanup handler, we'd hit the database only if it was
more than a minute ago that we checked.
==
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Perrin Harkins <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 13:35:44 -0800 (PST)
On Wed, 14 Feb 2001, Pierre Phaneuf wrote:
> I think you are over-evalutating the stress on my server. With the
> speediest time base I was talking about (once per minute cron job), that
> would be 1440 HEAD requests per day, each requiring 1 simple database
> query that will most probably return no row at all (a query that returns
> many rows is slower, because it has to transmit these rows).
>
> Many sites with database-driven pages have multiple complex queries on
> some pages and run in the millions of page-views per day.
Sure, but why waste resources?
> As for the simplicity, having multiple individual custom cron jobs is
> simpler than one single generic cron job?
Yes, much simpler, at least for the scheduling and dispatching part.
Instead of designing database tables to hold timing info on jobs and code
to check it that is smart enough to remember when it last ran and prevent
race conditions, you can write a simple crontab with one call to wget per
job. The actual implementation of the jobs is pretty much identical
either way.
Do it whatever way suits you. I'm just suggesting that you try the lazy
way if possible.
> I was thinking of having a variable with a timestamp of when we last
> checked the database
That will have to be some sort of shared memory or file-based thing, since
you won't be using the same process each time.
===
To: Perrin Harkins <perrin@primenet.com>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 19:00:10 -0500
Perrin Harkins wrote:
> Sure, but why waste resources?
Because it's easy? :-)
> > As for the simplicity, having multiple individual custom cron jobs is
> > simpler than one single generic cron job?
>
> Yes, much simpler, at least for the scheduling and dispatching part.
> Instead of designing database tables to hold timing info on jobs and
> code to check it that is smart enough to remember when it last ran
> and prevent race conditions, you can write a simple crontab with one
> call to wget per job. The actual implementation of the jobs is
> pretty much identical either way.
I guess two persons "simpler" aren't always the same: I find it easier
laying out a table and querying it than hacking something to fiddle with
my crontab safely.
> Do it whatever way suits you. I'm just suggesting that you try the lazy
> way if possible.
I could mash the two together: have a single URL trigger that looks up
the tasks to do in a database, but have it schedule it's next run itself
using "at". Whew, there *is* a whole lot more than one way to do it! :-)
> > I was thinking of having a variable with a timestamp of when we last
> > checked the database
>
> That will have to be some sort of shared memory or file-based thing, since
> you won't be using the same process each time.
I was intending on being lazy and let a bunch of processes find out
there is nothing to do because one of them already did the work. ;-)
Ahh, the joy of wasting resources...
Would anyone be interested in seeing an Apache::Schedule, with an API
similar to the Tcl API in AOLserver?
http://aolserver.com/docs/tcldev/tapi-114.htm
http://aolserver.com/docs/tcldev/tapi-113.htm
http://aolserver.com/docs/tcldev/tapi-115.htm
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Perrin Harkins <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 16:29:05 -0800 (PST)
On Wed, 14 Feb 2001, Pierre Phaneuf wrote:
> I guess two persons "simpler" aren't always the same: I find it easier
> laying out a table and querying it than hacking something to fiddle with
> my crontab safely.
As far as I know, crontab -e is perfectly safe.
===
To: modperl@apache.org
From: Robert Landrum <rlandrum@capitoladvantage.com>
Subject: Re: cron for mod_perl?
Date: Wed, 14 Feb 2001 20:40:17 -0500
Perhaps I've missed something, but in all this discussion no one has
asked what it is you're trying to do. All I know is that you want to
schedule something in a database and then check that database every
minute (or so) and process the scheduled somethings.
Generally speaking, 'at' is the simplest alternative. I've used 'at'
in similar circumstances (though never from the web). However, this
does not meet your needs of using a cached database connection.
Another possibility is to write a daemon yourself and use some type
of IPC or RPC to schedule events to that daemon. As the daemon runs,
it just forks off and processes the scheduled jobs as those times
pass. This requires some crafty work with sig alarm or other
mechanism. I once remember seeing an alarm lib somewhere that would
allow you to set more than one alarm.
Without knowing what it is you're trying to implement, I think we've
just about exhausted the possibilities for a scheduler within
mod_perl/apache.
Robert Landrum
===
To: Perrin Harkins <perrin@primenet.com>
From: Ask Bjoern Hansen <ask@valueclick.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 03:21:45 -0800 (PST)
On Wed, 14 Feb 2001, Perrin Harkins wrote:
> On Wed, 14 Feb 2001, Pierre Phaneuf wrote:
> > I guess two persons "simpler" aren't always the same: I find it easier
> > laying out a table and querying it than hacking something to fiddle with
> > my crontab safely.
>
> As far as I know, crontab -e is perfectly safe.
"crontab -l | foo" and "foo | crontab -" are your friends.
as for putting cron into Apache: I don't understand why that's wanted
in the first place. When connecting to the database outside the httpd
it doesn't matter if it goes a little slow. And having separate
programs to do the maintenance would easily be much simpler than
trying to drop everything into the httpd.
All this might of course be way off since it's not really clear to me
what the real goal is in the first place. (this thread has been kinda
like "I want to use facility Y", instead of
``I want to accomplish X.
I thought I might be able to use facility Y.
But Y doesn't seem like it's quite right, because of Z.
What should I use instead of Y, or how can I overcome Z?''[1]
:-)
So: What is the task at hand (more than "run something at certain
intervals" (which is what cron(8) is for)).
- ask
[1] http://perl.plover.com/Questions.html
===
To: Ask Bjoern Hansen <ask@valueclick.com>
From: Matt Sergeant <matt@sergeant.org>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 12:12:32 +0000 (GMT)
On Thu, 15 Feb 2001, Ask Bjoern Hansen wrote:
> On Wed, 14 Feb 2001, Perrin Harkins wrote:
>
> > On Wed, 14 Feb 2001, Pierre Phaneuf wrote:
> > > I guess two persons "simpler" aren't always the same: I find it easier
> > > laying out a table and querying it than hacking something to fiddle with
> > > my crontab safely.
> >
> > As far as I know, crontab -e is perfectly safe.
>
> "crontab -l | foo" and "foo | crontab -" are your friends.
>
> as for putting cron into Apache: I don't understand why that's wanted
> in the first place. When connecting to the database outside the httpd
> it doesn't matter if it goes a little slow. And having separate
> programs to do the maintenance would easily be much simpler than
> trying to drop everything into the httpd.
Its just a convenience thing. I've wanted to be able to do this too, for
example to have emails go off at a particular interval. So yes, it can be
done as cron + URI, but I'm just jealous of AOLServer's ability to do it
all in one. This is especially important for a shrink-wrapped type
application, where asking people to install a crontab entry is just
another pain in the installation process (note that cron might be
different on different OS's, and so might the shell be, so this is a real
problem for some people - whereas if it were in Apache we'd know the
platform).
===
To: modperl@apache.org
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 08:41:31 -0500
Ask Bjoern Hansen wrote:
> So: What is the task at hand (more than "run something at certain
> intervals" (which is what cron(8) is for)).
I am building a web something-something (I don't know what's the current
buzzword for that, you know, the big integrated things) similar to the
ArsDigita Community System (ah, I bet this helped a lot more! :-) ).
My first occurence of this need was about expiring session keys from the
database. At first, I was about to do a little query that run from a
cleanup handler every so many seconds, but after that, I was stealing
some more ideas from ACS (it's a very good idea, but AOLserver and Tcl,
ick!), and I was getting jealous of the AOLserver scheduler, which they
use abundantly.
For example, you can check a list of URLs at regular interval to see if
your machines are up (and get a warning if some are not), or you can
send warnings to users when their car is about to get towed away because
of parking regulations. :-)
Anyway, from fussing around in ACS, it came to me that a general
scheduler is a pretty good idea, so I set to it.
More about the rationale in another reply to Matt Sergeant...
> [1] http://perl.plover.com/Questions.html
Very good one, I almost died of a chocolate-covered banana indigestion.
:-)
===
To: modperl@apache.org
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 08:47:48 -0500
Ask Bjoern Hansen wrote:
> > > I guess two persons "simpler" aren't always the same: I find it easier
> > > laying out a table and querying it than hacking something to fiddle with
> > > my crontab safely.
> >
> > As far as I know, crontab -e is perfectly safe.
>
> "crontab -l | foo" and "foo | crontab -" are your friends.
Ah yes. The problem with this is between the "crontab -l" and the
"crontab -". You have to parse the crontab, find your own entry without
disturbing other entries, mix in your new/modified entry, etc... Not
that it's impossible, but I don't like this very much and I find
INSERT/SELECT/UPDATE easier.
Also, I'm not totally sure a piped open would be okay in Apache, since
this has a fork() underneath. Probably that it cannot be done in the
obvious straightforward way, 'open("crontab -l |")'. I would have to go
through the Apache subprocess API and do things I'd rather not be doing
(hey, I was the one annoyed by path_info not being translated for me :-)
).
Call me lazy. :-)
===
To: "modperl@apache.org" <modperl@apache.org>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 09:04:43 -0500
Matt Sergeant wrote:
> > as for putting cron into Apache: I don't understand why that's wanted
> > in the first place. When connecting to the database outside the httpd
> > it doesn't matter if it goes a little slow. And having separate
> > programs to do the maintenance would easily be much simpler than
> > trying to drop everything into the httpd.
>
> Its just a convenience thing. I've wanted to be able to do this too, for
> example to have emails go off at a particular interval. So yes, it can be
> done as cron + URI, but I'm just jealous of AOLServer's ability to do it
> all in one. This is especially important for a shrink-wrapped type
> application, where asking people to install a crontab entry is just
> another pain in the installation process (note that cron might be
> different on different OS's, and so might the shell be, so this is a real
> problem for some people - whereas if it were in Apache we'd know the
> platform).
Same reasons here for wishing for this. By the way, it could even be
done as "cron + perl script that does the job directly (outside of
Apache)", but I'm trying to integrate things, so that you start one DBMS
daemon and N Apache servers (on different machines, of course), and you
have the application running.
As you mention, there is also the problem of being cross-platform.
Apache and mod_perl runs on Windows, but I would have to make people get
themselve a cron for Windows?
I think that I *will* make an Apache::Schedule module, but much less
ambitious and more closely related to the way Apache and mod_perl do
things. What about this summary:
Apache::Schedule let you register callbacks (per Apache child process)
that will be called after a given amount of time has passed, either once
or repeatedly. Callbacks will be called at the next request after the
required time, or at child exit time.
Would anyone find that useful? Of course, you can always run it from
cron. Or make yourself a daemon. Or use POE. Or use Zope. Or (even) use
AOLserver. TMTOWTDI.
Is there a mod_perl for AOLserver? ;-)
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Dave Rolsky <autarch@urth.org>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 08:56:09 -0600 (CST)
On Thu, 15 Feb 2001, Pierre Phaneuf wrote:
> Would anyone find that useful? Of course, you can always run it from
> cron. Or make yourself a daemon. Or use POE. Or use Zope. Or (even) use
> AOLserver. TMTOWTDI.
This definitely might be useful, for the reasons you and Matt stated.
> Is there a mod_perl for AOLserver? ;-)
I remember hanging out on IRC one day and somebody there was talking about
it. Its still in early days but he seemed pretty into it. One thing I
suggested was he try to emulate the Apache API as much as possible, which
would make it possible to have cross-platform compatible mod_perl code.
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Tim Bunce <Tim.Bunce@ig.co.uk>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 14:59:16 +0000
On Thu, Feb 15, 2001 at 09:04:43AM -0500, Pierre Phaneuf wrote:
>
> Apache::Schedule let you register callbacks (per Apache child process)
> that will be called after a given amount of time has passed, either once
> or repeatedly. Callbacks will be called at the next request after the
> required time, or at child exit time.
Would it work even if the server is not getting any requests?
And if so, how?
===
To: Pierre Phaneuf <pp@ludusdesign.com>
From: Stas Bekman <stas@stason.org>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 23:02:04 +0800 (SGT)
On Thu, 15 Feb 2001, Pierre Phaneuf wrote:
> Ask Bjoern Hansen wrote:
>
> > > > I guess two persons "simpler" aren't always the same: I find it easier
> > > > laying out a table and querying it than hacking something to fiddle with
> > > > my crontab safely.
> > >
> > > As far as I know, crontab -e is perfectly safe.
> >
> > "crontab -l | foo" and "foo | crontab -" are your friends.
>
> Ah yes. The problem with this is between the "crontab -l" and the
> "crontab -". You have to parse the crontab, find your own entry without
> disturbing other entries, mix in your new/modified entry, etc... Not
> that it's impossible, but I don't like this very much and I find
> INSERT/SELECT/UPDATE easier.
I might be barking at the wrong tree, but why cron? Why don't you use
at(1). you don't need to parse crontab for that, and you can spawn
processes with whatever intervals on demand. basically you can call
at(1) itself at the end of at() so you can do the same as crontab.
See http://man.he.net/man1/at
(I don't seem to find the manpage for at(1) on Mandrake box :(
====
To: modperl@apache.org
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 10:41:21 -0500
Stas Bekman wrote:
> I might be barking at the wrong tree, but why cron? Why don't you use
> at(1). you don't need to parse crontab for that, and you can spawn
> processes with whatever intervals on demand. basically you can call
> at(1) itself at the end of at() so you can do the same as crontab.
Yes, at is much better suited, but you still have the problem of forking
under Apache (possible, but hairy) and systems where there is no at.
===
To: Tim Bunce <Tim.Bunce@ig.co.uk>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 10:42:45 -0500
Tim Bunce wrote:
> > Apache::Schedule let you register callbacks (per Apache child process)
> > that will be called after a given amount of time has passed, either once
> > or repeatedly. Callbacks will be called at the next request after the
> > required time, or at child exit time.
>
> Would it work even if the server is not getting any requests?
> And if so, how?
No, that's the problem. :-)
That's where my idea of a cron job that does a HEAD request on an URL
that has the cleanup handler installed every 30 minutes (say) comes
from, so that there is a minimum level of service.
But while I would mention that in the README, that is outside the scope
of the perl module to do and left to the individual user. The
restriction would be clearly documented, and here's a way to help out
with it, but if it doesn't do what you want, don't use it (or tell us
how to improve it).
AOLserver has it easy, being in a single process and having this
scheduler tied in at the select() level, it never misses a beat and is
always on time (to a few tens or hundreds of milliseconds, if the server
is not overloaded). Apache is more complicated, with multiple child
processes that die after a while and don't know about each other (and
cannot depend on one particular child process to be there) and so on.
You could put something in the Apache parent process, but that would
require a new hook in Apache itself. That would be cool, but still not
free of problems:
- the parent process often runs with root privileges, do we run the
scheduled callback as root inside the parent process?
- if we do, if it is long running, you could have problems with Apache
Maybe it could register an URL to invoke on itself? Anyway, I'm not
enough into Apache to do something like *that*, even though I'd love
to...
===
To: modperl@apache.org
From: Vivek Khera <khera@kciLink.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 15:03:08 -0500
>>>>> "PP" == Pierre Phaneuf <pp@ludusdesign.com> writes:
>> > As far as I know, crontab -e is perfectly safe.
>>
>> "crontab -l | foo" and "foo | crontab -" are your friends.
PP> Ah yes. The problem with this is between the "crontab -l" and the
PP> "crontab -". You have to parse the crontab, find your own entry without
Very limited thinking going on here. The crontab program honors the
EDITOR environment variable. Now... setenv EDITOR=myscript then run
crontab -e. Poof. Atomic update. With appropriate Perl modules for
the cron files, this should be trivial. But then, you probably aren't
doing this from mod_perl...
===
To: Stas Bekman <stas@stason.org>
From: Perrin Harkins <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 12:12:45 -0800 (PST)
On Thu, 15 Feb 2001, Stas Bekman wrote:
> I might be barking at the wrong tree, but why cron? Why don't you use
> at(1).
And there's a CPAN module for it: Schedule::At. It claims to be
cross-platform, and I believe NT has a version of at(1).
- Perrin
===
To: modperl@apache.org
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 15:19:54 -0500
Vivek Khera wrote:
> PP> Ah yes. The problem with this is between the "crontab -l" and the
> PP> "crontab -". You have to parse the crontab, find your own entry without
>
> Very limited thinking going on here. The crontab program honors the
> EDITOR environment variable. Now... setenv EDITOR=myscript then run
> crontab -e. Poof. Atomic update.
That's what I intended to do (that's why I didn't mention concurrency
problems), but you still have to fork, which is hairy under mod_perl.
> With appropriate Perl modules for the cron files, this should be
> trivial. But then, you probably aren't doing this from mod_perl...
Well, yes, why? :-)
===
To: Matt Sergeant <matt@sergeant.org>
From: Perrin Harkins <perrin@primenet.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 12:22:19 -0800 (PST)
On Thu, 15 Feb 2001, Matt Sergeant wrote:
> Its just a convenience thing. I've wanted to be able to do this too, for
> example to have emails go off at a particular interval. So yes, it can be
> done as cron + URI, but I'm just jealous of AOLServer's ability to do it
> all in one. This is especially important for a shrink-wrapped type
> application, where asking people to install a crontab entry is just
> another pain in the installation process (note that cron might be
> different on different OS's, and so might the shell be, so this is a real
> problem for some people - whereas if it were in Apache we'd know the
> platform).
Maybe we should add process scheduling into Apache, and a file system, and
a window manager, and...
Okay, I'm being silly, and there are times when duplication is necessary,
but cron is such a well-established way of solving this problem that
anything else sounds strange.
The original post didn't say that the goal was to modify the scheduled
jobs dynamically from mod_perl, and that does add a new wrinkle. I still
think a good Perl interface to cron would be more obvious and more
reliable.
===
To: modperl@apache.org
From: Vivek Khera <khera@kciLink.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 15:34:30 -0500
>>>>> "PP" == Pierre Phaneuf <pp@ludusdesign.com> writes:
>> With appropriate Perl modules for the cron files, this should be
>> trivial. But then, you probably aren't doing this from mod_perl...
PP> Well, yes, why? :-)
You really want to have your web server writing files that execute
arbitrary programs at arbitrary times? Sounds risky.
===
To: Perrin Harkins <perrin@primenet.com>
From: Matt Sergeant <matt@sergeant.org>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 20:37:43 +0000 (GMT)
On Thu, 15 Feb 2001, Perrin Harkins wrote:
> Maybe we should add process scheduling into Apache, and a file system, and
> a window manager, and...
:-)
> Okay, I'm being silly, and there are times when duplication is necessary,
> but cron is such a well-established way of solving this problem that
> anything else sounds strange.
>
> The original post didn't say that the goal was to modify the scheduled
> jobs dynamically from mod_perl, and that does add a new wrinkle. I still
> think a good Perl interface to cron would be more obvious and more
> reliable.
Perhaps its the difference between people who've had to write shrink-wrap
apps? The question for me is dependencies. We add in Schedule::Cron or
whatever and then you've got to add in LWP or HTTP::GHTTP or HTTP::Lite
to do the request. Its just something that would be useful to a lot of
people, IMHO.
===
To: "modperl@apache.org" <modperl@apache.org>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 15:44:13 -0500
Perrin Harkins wrote:
> The original post didn't say that the goal was to modify the scheduled
> jobs dynamically from mod_perl, and that does add a new wrinkle. I still
> think a good Perl interface to cron would be more obvious and more
> reliable.
Sorry, maybe I didn't make that quite clear. Yes, it is a goal. For
example, to take an example from the ACS, a user can add or remove
parking warnings from the web site. I could write a file somewhere and
have another process in cron process that file every once in a while,
but I would like direct and immediate feedback/effect.
This could be simply an Apache::Cron module or something like that, to
ease the task of add/modifying/removing cron jobs from mod_perl, I
agree.
===
To: Vivek Khera <khera@kciLink.com>
From: Pierre Phaneuf <pp@ludusdesign.com>
Subject: Re: cron for mod_perl?
Date: Thu, 15 Feb 2001 16:04:06 -0500
Vivek Khera wrote:
> >> With appropriate Perl modules for the cron files, this should be
> >> trivial. But then, you probably aren't doing this from mod_perl...
>
> PP> Well, yes, why? :-)
>
> You really want to have your web server writing files that execute
> arbitrary programs at arbitrary times? Sounds risky.
Well, I'd like to keep this as little arbitrary that I can. For examples
of what I'd like to be able to do:
http://tz.arsdigita.com/
http://remindme.arsdigita.com/
http://uptime.arsdigita.com/uptime/
The last one fetches URLs from the web.
As for risky: this is just as risky as using mod_perl at all. What is
run is controlled by the script, so it's not 100% arbitrary, if you can
help it. If it was inside Apache, then it wouldn't be arbitrary
programs, it would restricted to the server.
===
To: <modperl@apache.org>
From: "Les Mikesell" <lesmikesell@home.com>
Subject: Re: cron for mod_perl?
Date: Sat, 3 Mar 2001 09:33:07 -0600
> From: Matt Sergeant <matt@sergeant.org>
> On Thu, 15 Feb 2001, Perrin Harkins wrote:
>
> > Maybe we should add process scheduling into Apache, and a file system, and
> > a window manager, and...
>
> Perhaps its the difference between people who've had to write shrink-wrap
> apps? The question for me is dependencies. We add in Schedule::Cron or
> whatever and then you've got to add in LWP or HTTP::GHTTP or HTTP::Lite
> to do the request. Its just something that would be useful to a lot of
> people, IMHO.
I'm not sure why you would want a perl cron-alike under unix unless you
are doing something so frequently that you don't want to reload perl for
every run, but it would be handy to have a scheduling module that would
work on windows NT or Win2k to provide the missing cron functionality.
===