The Inside Out

Cron y At - Daemons de agenda

En determinadas ocasiones necesitaremos ejecutar programas a intervalos constantes, o en momentos fijos del día. Un ejemplo sería recibir por mail un aviso sobre las actualizaciones hechas al sistema, recibido todos los fines de semana. En general, estamos buscando ejecutar un trabajo (un job, que le llaman) cada cierto tiempo.

Este tipo de servicio esta provisto en GNU/Linux (y en Unix en general) por los daemons cron y at. Ambos están compuestos por un Daemon y varias utilidades de contorno. Ambos sistemas proveen un cierto nivel de seguridad, mediante archivos que dan o niegan permisos a los usuarios para hacer uso de esta funcionalidad. Cron y At tienen varias diferencias, siendo posiblemente la principal la de cómo especificar un momento o intervalo de repetición en uno y en otro. Empecemos por Cron.

cron

El Vixie Cron (diseñado por Paul Vixie), que es el comúnmente provisto por las diferentes distribuciones GNU/Linux, lee los trabajos a ser realizados de archivos denominados 'crontabs' (Tablas de Cron). Hay un crontab general, en /etc/crontab, que tiene un formato diferente a los crontab de cada usuario, que se guardan en el directorio /var/spool/cron/tabs. Cada archivo tendra un nombre que sera el del usuario que creo cada tab. Por ejemplo, la PC Edhellond tendría un archivo en /var/spool/cron/tabs: rogelio. Más adelante veremos lo que ese archivo puede contener.

La única diferencia entre /etc/crontab y los crontabs de usuario es que el primero agrega un campo adicional donde se especifica bajo qué usuario se ejecutarán las tareas, con lo que el usuario root podría ahorrarse el trabajo de editar crontabs individuales y directamente trabajar sobre un archivo general (Esto es particularmente ventajoso si se usa scripting para manipular los crontabs).

Antes de ver el formato interno de los crontabs, hablemos del daemon cron. Este servicio es iniciado por root mediante el comando 'cron', generalmente llamándolo en el inicio del sistema desde algun script de /etc/rc.d. Al iniciarse carga todos los crontabs, y luego espera hasta tener que ejecutar alguna tarea. Tambien se encarga de enviar por e-mail la salida de los comandos ejecutados en las tareas, esto último solo si la variable MAILTO (que veremos enseguida) tiene definido algún valor de usuario destino. Si MAILTO se define como "" (vacía), entonces no se enviará ningun e-mail. Esto es muy útil para testear el sistema y estar seguros de que un trabajo funciona bien. Si se le define un cierto valor no vacío, veremos el reporte en el e-mail de dicho usuario. Una vez que todo funciona, podemos usar MAILTO="" en el crontab. Si no especificamos un valor (incluso si escribimos un espacio vacío) para MAILTO, entonces el e-mail se enviara al usuario dueño de dicho crontab, o si es el /etc/crontab, a root. Tambien se puede especificar una dirección de e-mail cualquiera. Note que normalmente el mail se recibe usando el comando de consola mail, parte del paquete mailx, o configurando una cuenta local de tipo mbox en su cliente de correo.

La utilidad crontab es la que nos permite editar los archivos crontabs, sea el nuestro personal, o el de otro usuario (esto sólo si somos root, claro). El comando posee 4 opciones que nos permiten Editar ('-e'), Remover ('-r') o Listar ('-l') el crontab del usuario especificado con -u USUARIO, o si no usamos esta opción, el nuestro.

Ejemplos:

• Para editar nuestro crontab: crontab -e
• Para editar el crontab del usuario buanzo: crontab -u rogelio -e
• Para eliminar nuestro crontab: crontab -r
• Para listar el crontab del usuario marcos: crontab -u marcos -l

El listar equivale a hacer cat /var/spool/cron/tabs/USUARIO, pero por los permisos de dichos directorios, solo podremos hacerlo como root. Recuerde que el daemon cron funciona como root, y tiene privilegios para leer el archivo y mostrárselo al usuario que lo haya solicitado.

Ahora sí, veamos un crontab de usuario real, para poder entender mejor el formato:

SHELL=/bin/bash
MAILTO=""
*/10 * * * *       /usr/local/bin/fetchmail

Aca vemos dos variables: SHELL y MAILTO. La primera indica que se debe utilizar el shell /bin/bash para ejecutar el comando de cada tarea. Luego vemos el uso de MAILTO, que en este caso esta vacío, por lo que no se enviara un email de reporte. Hay otras variables que podemos tocar, como HOME, pero no asi LOGNAME. (man 5 crontab para mas datos).

Luego vemos una línea más compleja, que consta de 6 campos:

1. minuto (0 al 59)
2. hora (0 al 23)
3. día (1 al 31)
4. mes (1 al 12, o nombres)
5. día de la semana (0 al 7, 0=7=Domingo, o sus nombres)
6. Comando a ejecutar (o script, cualquier cosa ejecutable). Aquí se pueden incluir parámetros, etc.

El valor * indica "a cualquier [hora/dia/etc]". Y el */ALGO indica "ejecutar cada cierto ALGO". Entonces, en el ejemplo, cada diez minutos ('*/10') de cualquier dia, mes, etc, se ejecutara el comando /usr/bin/fetchmail, que buscará el correo.

Hay otros formatos de campo que se pueden utilizar para realizar ciertas tareas, pero los remito a la man page del crontab, seccion 5.

En el caso del archivo /etc/crontab, el campo 6 pasa a ser el usuario con el que ejecutar el comando, que vendrá despues, en el campo 7 agregado. Vean su propio archivo /etc/crontab, que contiene varias cosas, entre las cuales hay algunas tareas bastante interesantes, como las que definen que los scripts almacenados en /etc/cron.{hourly/weekly/daily} se ejecuten cada hora, semana o día:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root nice -n 19 run-parts /etc/cron.hourly
02 4 * * * root nice -n 19 run-parts /etc/cron.daily
22 4 * * 0 root nice -n 19 run-parts /etc/cron.weekly
42 4 1 * * root nice -n 19 run-parts /etc/cron.monthly

Ahora, los archivos allow y deny, que se guardan en /var/spool/cron, son los que manejan qué usuarios pueden o no utilizar cron. El mecanismo es el siguiente: si el archivo allow existe, un usuario debe estar incluído en él para que se le de permiso. Si allow NO existe, pero existe deny, entonces un usuario NO DEBE estar dentro para permitírsele la ejecucion. Si no existe ninguno de estos dos archivos, los permisos concedidos dependen de la configuración del sistema (por ejemplo, sólo root o TODOS podrán usarlos). Por otra parte, se puede hacer que el comando crontab pertenezca a cierto grupo, y que los permisos de ejecución para los demás sean nulos. Luego, deberemos hacer miembro de ese grupo a cada usuario al que queramos darle permiso. Por supuesto, podemos combinar todas las medidas de seguridad que nos parezcan necesarias.

at

El servicio at tiene básicamente la misma funcionalidad, sólo cambia el formato con el que se especifica un 'momento'. Tiene una sintaxis muy parecida al idioma inglés. Daremos ejemplos para que esto se entienda mejor, pero antes debemos comprender que At no ejecuta un comando o script, sino una serie de comandos, que At nos solicitara interactivamente. Tambien podemos especificar un script (y NO un binario) para que sea ejecutado, mediante el parametro '-f', que ahora veremos.

Ejemplos para comprender mejor el uso de at:

• at midnight Ejecutará a la medianoche el script que ingresemos interactivamente al ejecutar el comando. Tambien podemos usar noon (mediodía) o teatime (4pm). Por otra parte, podemos agregar today (hoy) o tomorrow (mañana) como sufijo: at 8:30am tomorrow (a las 8.30 am de mañana).
• at 3:15pm Ejecutará a las 3:15 de la tarde.
• at now + 2 days Ejecutará a esta hora dentro de dos dias.
• at 10am + 1 week Ejecutará a las 10am dentro de una semana.
• at 11pm Jul 22 Ejecutará a las 23hs del 22 de Julio

Usando el parametro '-f', podríamos hacer: at -f ~/algun_script now + 10 minutes (ejecutar el script ~/algun_script dentro de 10 minutos a partir de ahora). En vez de usar day[s], week[s], también podemos usar minute[s], hour[s]. El now indica "AHORA".

Se pueden además especificar fecha y hora con los siguientes formatos: HH:MM (hora:minutos), MMDDYY o MM/DD/YY o DD.MM.YY (día mes año).

Los diferentes comandos que hacen al paquete AT son:

• atd: El daemon at. Como cron, se debe cargar desde un script de /etc/rc.d
• at: El comando at propiamente dicho. Vea los ejemplos arriba y abajo.
• atq: Ver la lista de trabajos ('jobs') pendientes.
• atrm: Para eliminar un trabajo pendiente de la cola (queue).
• batch: Como at, pero ejecutara el script cuando el nivel de carga del sistema haya bajado lo suficiente. (default, 0.8).

El comando atq (at query, consultar at) equivale a at con el parametro '-l', y atrm es at, pero con el parametro '-d'. At tambien admite el parametro '-m', que enviara un e-mail al usuario una vez realizado el trabajo.

Para permitir o negar el uso de at podemos hacer lo mismo que con cron, y los archivos Allow y Deny se encuentran en /etc/at.allow y /etc/at.deny, y se respeta el mismo esquema que en Cron.

Esto ha sido todo. Esperamos que ahora puedan combinar su conocimiento de scripts de bash con la posibilidad de "agendar" que les da este tutorial. El último tema por ver en la serie de tutoriales de shell es el de conceptos de usuarios y permisos. Este tutorial le permitirá entender una parte importante del esquema de seguridad en Linux, y se aplica a todo lo que ha visto hasta ahora.

Este artículo fue adaptado del original, escrito por Arturo Alberto Busleiman. Se publica aquí con expreso consentimiento del autor. Copyleft de este artículo para Arturo Alberto Busleiman.