Cron

Saltar a: navegación, buscar

Esta página necesita actualizarse con la información existente en la documentación vigente/moderna/actualizada en el idioma inglés original para Moodle. Se le sugiere al lector que consulte la página original en idioma inglés cuyo enlace está al fondo de esta página. y que, por favor, actualice esta información y quite la plantilla {{Actualizar}} cuando haya terminado.     (otras páginas pendientes de actualizar)


El proceso 'cron' de Moodle es un script PHP (parte de la instalación estándar de Moodle) que debe ejecutarse regularmente en segundo plano. El script cron de Moodle corre diferentes trabajos/tareas (tasks) a diferentes intervalos agendados.

IMPORTANTE: No se salte la configuración del proceso de cron en su servidor de Moodle. Su sitio no funcionará correctamente sin él.

Un programa especial (típicamente llamado - lo que no es de sorprender - 'cron') es usado para ejecutar el script de cron de Moodle a intervalos regulares. El script de cron de Moodle corre trabajos/tareas que incluyen el mandar correos, actualizar reportes de Moodle, canales RSS, completado de actividades, publicación de mensajes en foros y otros trabajos. Dado que los diferentes trabajos tienen diferentes horarios agendados, no todos los trabajos correrán en Moodle cuando se dispare el script de cron.

Se recomienda que se ejecute el trabajo cron cada minuto, pues así lo necesita la eliminación asincrónica de actividades al usar la Papelera de reciclaje.

El programa cron (que corre el script de Moodle) es una parte del núcleo de los sistemas basados en Unix (incluyendo Linux y OSX) que se usa para correr todos los tipos de servicios dependientes del tiempo (hora). En Windows, la solución más simple es crear una tarea en el Administrador de tareas de windows ( Windows Task Scheduler ) y configurarla para que corra a intervalos regulares. En alojamientos compartidos, Usted debería de encontrar la documentación (o pedir soporte) acerca de cómo se configura cron. La mayoría de los sistemas de alojamiento web compartido usan CPanel para gestionar los sitios, y usualmente tendrán una sección para Cron Jobs (Trabajos Cron) en el panel.

Esencialmente, la tarea involucra el añadir un solo comando (instrucción/órden) a la lista de actividades de cron en su sistema. En sistemas basados en Unix, esta lista es un archivo llamado 'crontab' que todos los usuarios tienen.

Discusión general

Vea las secciones más adelante para su tipo de servidor; ésta sección contiene un poco de información general introductoria.

Esencialmente hay dos pasos para implementar cron:

  1. identificar el comando correcto a ejecutar
  2. encontrar el lugar correcto en su sistema para poner el comando

Elaboración del comando cron de Moodle

Moodle tiene dos diferentes formas para desplegar cron que usan diferentes scripts dentro de la instalación de Moodle. Éstos son como sigue...

  1. El script CLI (command line interpreter = intérprete de línea de comando) estará en la ruta
    /ruta/hacia/moodle/admin/cli/cron.php
    Si tiene dudas, éste es el script correcto para utilizar. Éste necesita correrse por un programa 'PHP CLI' en su computadora. Así es que, el comando final puede parecerse a algo similar a
    /usr/bin/php /ruta/hacia/moodle/admin/cli/cron.php
    Usted puede (y debería de) intentar ésto en su línea de comando para ver si funciona. ADVERTENCIA: Revise que su versión de PHP de línea-de-comando sea compatible con su versión elegida de Moodle. El programa de PHP de línea-de-comando es diferente del que está corriendo en su sitio web y no siempre es la misma versión.
  1. Si, por alguna razón Usted no puede correr el script de la Interfaz por Línea de Comando, hay una versión del scrpt basado en web. Tome nota de que ahora esto está deprecado y podría ser eliminado en futuras versiones de Moodle. El script basado en web necesita ejecutarse desde un navegador web y estará accesible mediante una URL web parecida a http://su.sitio.moodle/admin/cron.php. Usted puede encontrar un navegador web basado en línea de comando (por ejemplo, wget) por lo que el comando final podría parecerse a
    /usr/bin/wget http://su.sitio.moodle/admin/cron.php
    Ésto tiene la ventaja de que se puede ejecutar desde *cualquier sitio*. Si Usted no puede lograr que cron funcione en su computadora, puede ejecutarlo en otro sitio.

El comando cron de Moodle basado en web

Si Usted tiene la opción, no use el cron basado en web. Es probable que sea eliminado en una versión futura de Moodle.

  • A partir de Moodle 2.9, ya no puede invocarse el comando cron via web. Aparecerá el siguiente mensaje de error:
!!! Sorry, internet access to this page has been disabled by the administrator. !!! 
(Lo sentimos, el acceso por Internet a esta pagina ha sido desactivado por el administrador.)
  • Usted puede cambiar esto en 'Tablero ► Administración del sitio ► Seguridad ► Políticas del sitio' al desactivar la casilla de 'Ejecución de cron sólo mediante comandos'.
    • Usted recibirá una advertencia de que 'El correr el cron desde un navegador web puede exponer información privilegiada a usuarios anónimos. Por esto, se recomienda solamente correr cron desde la línea de comando o configurarle una contraseña a cron para el acceso remoto..'
    • Usted podrá entonces escribir una 'Contraseña de cron para acceso remoto'. Si este campo se deja vacío, no se necesita contraseña..
    • Esto significa que el script de cron.php no puede correrse desde un navegador de Internet sin proporcionar la contraseña, empleando la siguiente sintaxis de URL:
 http://sitio.ejemplo.com/admin/cron.php?password=abretesesamo

Encontrando el lugar correcto para poner el comando

Este realmente depende del sistema que estés usando y es importante que encuentres y leas la documentación de la plataforma u hospedaje donde te encuentres. En la mayoría de los casos el lograr ejecutar cron consiste en establecer el comando correcto (arriba) y el tiempo en que ejecutar el comando en algún archivo. Esto puede ser a través de la interfaz del usuario o editando el archivo directamente.

Si estas usando la Línea de Comando, debes de asegurarte que el proceso de cron sea ejecutado con el usuario correcto, esto no es un problema para la versión web.

Ejemplo... instalando cron en Linux Ubuntu/Debian. Asumiendo que te encuentras como el usuario root.

Usa el comando crontab para abrir la ventana del editor para el usuario www-data. Este es el usuario en que Apache (el servidor web) se ejecuta en los sistemas basados en Debian

$ crontab -u www-data -e

Esto abrirar una ventana del editor. Para ejecutar el cron en línea de comando cada minuto añade la línea:

* * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php >/dev/null

NOTA: El >/dev/null final envía todo el resultado del comando a nulo y evita que te se envíe un correo cada minuto; es útil quitarlo si no está funcionando como esperamos.

Configuración de cron en su sistema

Elija la información para su tipo de servidor:

Aquí hay más instrucciones para hosts específicos (por favor revise que estén actualizados):

Uso de servicios cron de terceros

Además de usar cron alojado en su propio servidor, Usted puede usar un servicio cron de terceros (lo que usualmente se llama webcron):

  • cron-job.org es un servicio gratuito. (es posible tener cron de 1Minuto)
  • EasyCron - Un proveedor de servicio webcron que elimina la necesidad de crontab o algun otro agendador de tarea para configurar el trabajo de cron.

Configuraciones de cron en Moodle

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!.     ( y otras páginas pendientes)

An admin can set cron execution via command line only or a cron password for remote access in 'Site security settings' in the Site administration.

Cron remoto

Using the 'web based' version of cron it is perfectly ok to place the cron process on a different machine to the Moodle server. For example, the cron service on a Unix server can invoke the cron web 'page' on a Windows based Moodle server.

Trabajos agendados

An administrator can schedule cron tasks very precisely from Administration > Site administration > Server > Scheduled tasks, see Trabajos agendados

Correr cron para varios servidores Moodle

  • Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.
  • If you are running different Moodle instances on the same server, then each Moodle instance needs a cron job. (Even a single Apache web server can run different Moodle instances on different domains by using its virtual hosts capability https://httpd.apache.org/docs/2.2/vhosts/index.html.)

Depuración de Trabajos agendados

Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to add some automated checking of the output of running cron (e.g. searching for the string "Cron completed at ").

In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the Trabajos agendados admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the ejecutor de trabajos agendados CLI and monitor the output.

Guardado de bitácoras y monitoreo

Ideally you should also be logging the output of cron somewhere and monitoring it for issues. You can monitor the overall status of cron to make sure there are no errors by visiting:

Site administration / Reports / System status (/report/status/index.php)

You can also wire this status report up to tools like Icinga / Nagios using the Check API (https://docs.moodle.org/dev/Check_API) cli commands or with the help of plugins like https://github.com/catalyst/moodle-tool_heartbeat.

/admin/cli/checks.php

If there are errors then you can get more details for recently run tasks from the Logs column on the Scheduled task page, but this won't show ad hoc task failures:

Site administration / Server / Tasks / Scheduled tasks (/admin/tool/task/scheduledtasks.php)

To see ad hoc task failures you either need to rerun the task manually yourself and see the errors, or you need to have already collected the logs for review. For a Moodle running on a single box you could log to a simple log file, or for a cluster you might want to use syslogd or similar, e.g.:

 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...

Trabajos ad-hoc de baja latencia

Each time cron is run, after the scheduled tasks the ad hoc tasks are also run. While scheduled tasks can run at most once a minute, ad hoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.

Instead you can run one or more dedicated ad hoc task processors which run in parallel to the main cron process.

 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

Starting from Moodle 3.9 the—keep-alive option runs like a daemon so when the queue is empty rather than exiting it waits for new tasks to be queued so it can start processing as soon as possible.

Escalando cron con varios procesos

As your site grows many of the scheduled tasks will take longer to complete, and also there will be more ad hoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:

 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
...
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of ad hoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.

By default only 3 scheduled tasks and 3 ad hoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:

Site administration > Server > Tasks > Task processing

config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50;  // Defaults to 3

Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.

You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. e.g. if you have 5 cli processes, but in the task queue there are 20 ad hoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of ad hoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.

Automated backups are the worst known offender, so hypothetically if you are running 50 ad hoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:

config.php:
$CFG->task_concurrency_limit = [
    'core\task\course_backup_task' => 25,
    'core_course\task\course_delete_modules' => 5,
];


Vea también

Using Moodle forum discussions: