Web2py Cron Example

The web2py cron provides the ability for applications to execute tasks at preset times, in a platform independent manner.

For each application, cron functionality is defined by a crontab file "ap-p/cron/crontab", following the syntax defined here (with some extensions that was web2py specific):

1 http://en.wikipedia.org/wiki/Cron#crontab_syntax


Here is an example:

1 0-59/1 * * * * root python /path/to/python/script.py

2 30 3 * * * root *applications/admin/cron/cLb_vacuum.py

3 */30 * * * * root **applications/admin/cron/something.py

4 ©reboot root *mycontroller/myfunction

5 ©hourly root *applications/admin/cron/expire_sessions.py

The last two lines in this example, use extensions to regular cron syntax to provide additional web2py functionality.

Web2py cron has a some extra syntax to support web2py application specifics.

If the task/script is prefixed with an asterisk (*) and ends with ".py", it will be executed in the web2py environment. This means you will have all the controllers and models at your disposal. If you use two asterisks (**), the MODELs will not be executed. This is the recommended way of calling as it has less overhead and avoids potential locking problems.


web2py does not generate tickets or meaningful tracebacks in shell mode (in which cron is run). Make sure that your web2py code runs without errors before you set it up as a cron task, as you will likely not be able to see them when run from cron.

Moreover, be careful how you use models. While the execution happens in a separate process, database locks have to be taken into account in order to avoid pages waiting for cron tasks that be blocking the database. Use the ** syntax if you don't need to use the database in your cron task.

You can also call a controller function. There is no need to specify a path. The controller and function will be that of the invoking application. Take special care about the caveats listed above. Example:

If you specify @reboot in the first field in the crontab file, the given task will be executed only once, on web2py startup. You can use this feature if you want to precache, check or initialize data for an application on web2py startup. Note that cron tasks are executed in parallel with the application — if the application is not ready to serve requests until the cron task is finished, you should implement checks to reflect this. Example:

1 @reboot * * * * root *mycontroller/myfunction


• Soft cron: available under all execution modes

• Hard cron: available if using the built-in web server (either directly or via Apache mocLproxy)

• External cron: available if you have access to the system's own cron service

The default is hard cron if you are using the built-in web server; in all other cases the default is soft cron.

Soft cron is the default if you are using CGI, FASTCGI or WSGI. Your tasks will be executed in the first call (page load) to web2py after the time specified in crontab (but after processing the page, so no delay to the user is visible). Obviously, there is some uncertainty exactly when the task will be executed depending on the traffic the site receives. Also, the cron task may get interrupted if the web server has a page load timeout set. If these limitations are not acceptable, see "external cron". Soft cron is a reasonable last resort, but if your web server allows other cron methods, they should be preferred over soft cron.

Hard cron is the default if you are using the built-in web server (either directly or via Apache mod_proxy). Hard cron is executed in a parallel thread, so unlike soft cron there are no limitations with regard to run time or execution time precision.



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


In case you do not need any cron functionality within a particular process, you can use the -N command line parameter to disable it. Note that this might disable some maintenance tasks (like the automatic cleaning of session dirs). The most common use of this function:

• You already have set up external cron triggered from the system (most common with WSGI setups)

If you want to debug your application without cron interfering either with actions or with output

Was this article helpful?

+2 -1

Post a comment