Introduction
CRON in web2py allows the task to be executed at intervals. Every program has a CRON file that lists all of its features. Scheduler By establishing the priority, the built-in scheduler assists in conducting the jobs in the background. It offers a method for establishing, planning, and changing tasks.
Now, without further, let's move into the topic of discussion.
Cron
Applications can execute tasks at predetermined times in a platform-independent manner using the web2py cron. A crontab file for each program defines the cron functionality:
app/cron/crontab.
Before web2py 2.1.1, cron could be turned off with the -N command-line option. It was enabled by default. Since version 2.1.1, cron is default turned off and can be turned on using the -Y option. This change was made to encourage users to use the new scheduler instead of the cron system, which may hurt performance.
Each application can have its unique cron setting, and changes to the cron configuration can be made within web2py without impacting the host OS.
Example 1👨💻
0-59/1 * * * * root python /path/to/python/script.py
30 3 * * * root *applications/admin/cron/db_vacuum.py
*/30 * * * * root **applications/admin/cron/something.py
@reboot root *mycontroller/myfunction
@hourly root *applications/admin/cron/expire_sessions.py
The final two lines of this example add more web2py capability using modifications to standard cron syntax.
A real file named "applications/admin/cron/expire sessions.py" comes with the admin app. It looks for sessions that have expired and delete them. This task is done every hour by "applications/admin/cron/crontab."
The task or script will be run in the web2py environment if preceded with an asterisk (*) and ends in.py. This indicates that you will have access to all controllers and models. The models won't run if there are two asterisks (**). This calling method is advised because it has lower overhead and prevents potential locking issues. You should be aware that scripts and functions run in the web2py environment must manually call db.commit() at the end of the function to avoid the transaction being rolled back.
Make sure your web2py code runs without errors before setting it up as a cron task because you probably won't be able to detect those errors when running from cron. After all, web2py does not generate tickets or meaningful tracebacks in shell mode, which is how cron is handled. Additionally, use models with caution. Although the execution occurs in a separate process, database locks must be considered to prevent pages from waiting for cron tasks that could be blocking the database. If you don't need to use the database in your cron task, use the ** syntax.
Another option is invoking a controller function, in which a path is unnecessary. The invoking application's Controller and function will be used. Pay close attention to the warnings mentioned above.
Example 2👨💻
*/30 * * * * root *mycontroller/myfunction
If @reboot is entered in the crontab file's first field, the specified task will only be run once upon web2py startup. You can utilize this capability if you wish to pre-cache, verify, or initialize data for an application on web2py startup. Cron tasks are conducted concurrently with the application; as a result, you should design checks to reflect that the application won't be ready to service requests until the cron task has been completed.
Example 3👨💻
@reboot root *mycontroller/myfunction
Depending on how you invoke it, there are four different ways to use web2py cron:
| Type | Description |
| Soft Cron | Available in all execution modes is soft cron. |
| Hard Cron | When utilizing the built-in web server, hard cron is accessible (directly or through Apache mod proxy). |
| External Cron | If you have access to the system's cron service, you can use an external cron. |
| No Cron |
If you use the built-in web server, hard cron is the default; otherwise, soft cron is the default. If you are utilizing CGI, FastCGI, or WSGI, soft cron is the default approach (but note that soft cron is not enabled by default in the standard wsgihandler.py file provided with web2py).
Your tasks will be carried out by soft cron on the first call (page load) to web2py following the time set in the crontab, but only after processing the page, so the user won't notice any delay. Depending on how much traffic the site receives, it is unsure exactly when the task will be completed. Additionally, if the web server has a page load timeout specified, the cron process may be halted. If these restrictions are intolerable, look into external cron. Although soft cron is a viable last resort, it should be avoided if your web server supports alternative cron techniques.
If you use the built-in web server (directly or through Apache mod proxy), hard cron is the default. Hard cron, unlike soft cron, has no run-time or execution time precision restrictions because it is executed in a parallel thread.
The system cron facilities must be used if you want to use external cron, which is not the default in any situation. It operates in a parallel process. Therefore none of soft cron's restrictions applies. The suggested method for utilizing cron with WSGI or FastCGI is as described above.
An example of a line to add to the system crontab, which is often found in /etc/crontab:
0-59/1 * * * * web2py cd /var/www/web2py/ && python web2py.py -J -C -D 1 >> /tmp/cron.output 2>&1
Make careful to specify either -J (or —cronjob, which is the same) when using an external cron so that web2py is aware that the task is being carried out by cron. Internally, Web2py sets this using soft and hard cron.
8+ registered 