Re: cron patch

[Massimo Di Pierro]

Hi Attila,

Uploaded your patch to trunk now! Excellent work!

Massimo

[David Marko]

Hi Massimo,
can you drop some example how to use it in application?

David

[achipa]

Long story short:

Make a cron directory in your app, and a crontab file in it. The
format of the file is regular crontab (you have an example for
cleaning sessions in the admin app). One special hook is if you prefix
the application with a *, it will execute a web2py controller
(basically a wrapper for calling python -S app -M....), but you have a
commented out example for that in the admin crontab, too.

If you're running standalone web2py (python web2py.py), or apache via
mod_proxy, you don't need to do anything, you get it for 'free', in a
spearate thread. This is know as 'hard cron' and is the recommended
cron mode. Tasks have no execution time limit.

If you're running CGI or WSGI/FASTCGI, by default you have 'soft cron'
which means that your tasks will be executed in the first call to
web2py after the time specified in crontab (but AFTER processing the
page, so no delay to the user is visible). Obviously, this has some
uncertainty exactly when the task will be executed. This is why we a
third mode, 'external cron'. Running cron tasks will be aborted when
the webserver stops or restarts.

Both soft and hard cron are platform independent, so even if you have
a windows machine, cron functionality will work without any changes.

External cron is called from the system crontab. It's recommended if
you're running WSGI/Fastcgi and you have root access. Add something
along these lines to your system crontab:

0-59/1 * * * * web2py cd /var/www/web2py/ &&
touch applications/admin/cron/cron.master && python web2py.py -C -D 1
>> /tmp/cron.output 2>&1

(change the paths to the ones on your system, of course, and the
username if it's not web2py). Note that external cron has it's own
output (and will thus not output stuff to the same console as web2py
like the other two cron modes).

That's it in a nutshell. If you have any problems with it just let me
know.

[Timothy Farrell]

Howzabout you make this into a wiki article under recipes?

-tim

--
Timothy Farrell <tfar...@swgen.com>
Computer Guy
Statewide General Insurance Agency (www.swgen.com)

[Iceberg]

Hi gentlemens,

web2py 1.56 with Achipa's cron patch is great. I just do a:
copy applications/admin/cron applications/myapp/cron
and then modify the applications/myapp/cron/crontab, replace the
"admin" by "myapp", then the long time puzzle "old sessions" ( see
http://groups.google.com/group/web2py/browse_thread/thread/f731c8f9d18811a2
) is solved! It is awesome!

I suggest the cron directory as well as the "expire old sessions"
ability should be enabled by default, otherwise almost each
application's session data is likely to consume all disk space hence
halt entire system sooner or later.

To do so, I suggest the welcome application should have its own cron/
expire_sessions.py etc. Further more, every new applications generated
by admin should better have its own cron/expire_sessions.py too. One
thing might be tricky here: currently the cron/crontab hardcode the
app name, so it need to be modified when being deployed into a new
application. Is there a way to make a same crontab which can work
inside different app, Achipa?

On Jan12, achipa <attila.cs...@gmail.com> wrote:
> Long story short:
>

> Make acrondirectory in your app, and a crontab file in it. The

> format of the file is regular crontab (you have an example for
> cleaning sessions in the admin app). One special hook is if you prefix
> the application with a *, it will execute a web2py controller
> (basically a wrapper for calling python -S app -M....), but you have a
> commented out example for that in the admin crontab, too.
>
> If you're running standalone web2py (python web2py.py), or apache via
> mod_proxy, you don't need to do anything, you get it for 'free', in a

> spearate thread. This is know as 'hardcron' and is the recommendedcronmode. Tasks have no execution time limit.

>
> If you're running CGI or WSGI/FASTCGI, by default you have 'softcron'
> which means that your tasks will be executed in the first call to
> web2py after the time specified in crontab (but AFTER processing the
> page, so no delay to the user is visible). Obviously, this has some
> uncertainty exactly when the task will be executed. This is why we a

> third mode, 'externalcron'. Runningcrontasks will be aborted when

> the webserver stops or restarts.
>

> Both soft and hardcronare platform independent, so even if you have
> a windows machine,cronfunctionality will work without any changes.
>
> Externalcronis called from the system crontab. It's recommended if

> you're running WSGI/Fastcgi and you have root access. Add something
> along these lines to your system crontab:
>
> 0-59/1 * * * * web2py cd /var/www/web2py/ &&
> touch applications/admin/cron/cron.master && python web2py.py -C -D 1
>
> >> /tmp/cron.output 2>&1
>
> (change the paths to the ones on your system, of course, and the

> username if it's not web2py). Note that externalcronhas it's own

[Markus Gritsch]

On Wed, Feb 11, 2009 at 11:21 AM, Iceberg <ice...@21cn.com> wrote:
>
> Hi gentlemens,
>
> web2py 1.56 with Achipa's cron patch is great. I just do a:
> copy applications/admin/cron applications/myapp/cron
> and then modify the applications/myapp/cron/crontab, replace the
> "admin" by "myapp", then the long time puzzle "old sessions" ( see
> http://groups.google.com/group/web2py/browse_thread/thread/f731c8f9d18811a2
> ) is solved! It is awesome!

Hmm, from looking at expire_sessions.py it seems that sessions in the
db (like when using web2py on GAE) do not get purged. So the session
table will sooner or later exceede the 500 MB datastore limit.

Markus

[achipa]

> To do so, I suggest the welcome application should have its own cron/
> expire_sessions.py etc. Further more, every new applications generated
> by admin should better have its own cron/expire_sessions.py too. One
> thing might be tricky here: currently the cron/crontab hardcode the
> app name, so it need to be modified when being deployed into a new
> application. Is there a way to make a same crontab which can work
> inside different app, Achipa?

Actually, that's already how expire_sessions.py work :)

path=os.path.join(request.folder,'sessions')

Hence it clears the session dir of whatever the request application
is. All you need to copy is the crontab file, no need to modify
anything on it, other than the reason that you need per-application
specifics in the expire_sessions.py. I do agree that it would make
sense to have expire_sessions as a default task for new web2py apps,
but that's Massimo's call.

As Markus pointed out, expire_sessions.py (which is just an example
for cron, albeit a useful one :) ) only deals with disk based
sessions. Not sure who's the original author, but patches for DB based
sessions are welcome, I don't have a DB based session setup at hand
and would like to avoid coding such thing 'blindly'.

[Markus Gritsch]

On Wed, Feb 11, 2009 at 1:36 PM, achipa <attila...@gmail.com> wrote:
>
> As Markus pointed out, expire_sessions.py (which is just an example
> for cron, albeit a useful one :) ) only deals with disk based
> sessions. Not sure who's the original author, but patches for DB based
> sessions are welcome, I don't have a DB based session setup at hand
> and would like to avoid coding such thing 'blindly'.

That's easy: Just add

session.connect(request,response,db=db)

in your db.py file to store sessions in a database table.

Markus