Tareas programadas en Linux: cron y timers

cron es un servicio del sistema Linux que se ejecuta permanentemente en segundo plano y cuya función es lanzar tareas de forma automática en momentos o intervalos predefinidos, sin necesidad de que nadie las inicie manualmente. Para ello, cron revisa periódicamente, en la práctica cada minuto, una lista de tareas programadas y ejecuta aquellas cuya hora de ejecución ha llegado. Esta lista de tareas se almacena en un archivo especial llamado crontab, en el que cada línea define una tarea junto con el momento en que debe ejecutarse. cron es la herramienta clásica y más extendida para automatizar el mantenimiento recurrente de un sistema, y resulta especialmente útil para tareas como realizar copias de seguridad periódicas, limpiar archivos temporales, rotar registros, sincronizar datos, generar informes o cualquier otra operación que deba repetirse con regularidad. Su valor es doble: por un lado ahorra el trabajo de acordarse de ejecutar estas tareas y hacerlo manualmente, y por otro garantiza que se realicen de forma fiable y consistente, siempre a la hora prevista, incluso cuando no hay nadie delante del equipo. Cada usuario del sistema puede tener su propio crontab con sus tareas, que se ejecutan con sus permisos, y existe además un crontab del sistema para las tareas administrativas. Para gestionar el crontab propio se usan comandos específicos que permiten editarlo y listarlo de forma segura, validando el formato.

Una línea de crontab se compone de cinco campos que especifican cuándo debe ejecutarse la tarea, seguidos del comando o script que se quiere ejecutar. Los cinco campos de tiempo van siempre en el mismo orden de izquierda a derecha y representan, respectivamente, el minuto, con valores de cero a cincuenta y nueve; la hora, de cero a veintitrés en formato de veinticuatro horas; el día del mes, de uno a treinta y uno; el mes, de uno a doce; y el día de la semana, de cero a seis, donde el cero corresponde al domingo. La combinación de estos cinco campos define el momento o la frecuencia de ejecución. Dentro de cada campo se pueden usar varios caracteres especiales que dan flexibilidad: un asterisco significa cualquier valor, es decir que ese campo no impone restricción; una lista de números separados por comas indica varios valores concretos; un guion entre dos números indica un rango de valores; y una barra seguida de un número indica una repetición cada tantas unidades. Así, por ejemplo, la combinación treinta en el minuto, dos en la hora y asteriscos en los tres campos restantes significa que la tarea se ejecuta a las dos y media de la madrugada todos los días; un cero en el minuto con asteriscos en el resto significa cada hora en punto; una barra quince en el campo del minuto con asteriscos en el resto significa cada quince minutos; y ceros en minuto y hora con un cero en el día de la semana significa a medianoche de cada domingo. Con la práctica, leer estas líneas se vuelve natural, y existen herramientas web que traducen las expresiones a lenguaje natural para ayudar mientras se aprende.

Que una tarea de cron no se ejecute como se esperaba es un problema muy común, y en la gran mayoría de los casos la causa está en un pequeño conjunto de errores típicos relacionados con el hecho de que cron ejecuta las tareas en un entorno distinto y mucho más reducido que el de una sesión interactiva del usuario. El primer error, y el más frecuente, es usar rutas relativas: cuando se ejecuta un comando manualmente, se hace desde una carpeta concreta y con un entorno que sabe dónde están las cosas, pero cron no parte de esa carpeta ni tiene ese contexto, de modo que hay que indicar siempre rutas absolutas tanto para el script que se ejecuta como para los archivos con los que trabaja. El segundo error es suponer que están definidas ciertas variables de entorno que en el contexto de cron no existen o tienen valores mínimos, en particular la variable que indica dónde buscar los programas, por lo que a veces hay que definir esas variables explícitamente o usar rutas absolutas también para los comandos. El tercer error es no redirigir la salida del comando a un archivo de registro, lo que deja al usuario completamente a ciegas sobre qué ha ocurrido, ya que sin registro no hay forma de ver los mensajes de error; redirigir tanto la salida normal como la de errores a un archivo permite diagnosticar el problema. Otros motivos habituales son que el script no tenga permiso de ejecución o carezca de su línea inicial de intérprete, o pequeños errores en la especificación de los tiempos. La estrategia recomendada para depurar es precisamente añadir registro de la salida y revisarlo tras la siguiente ejecución.

cron y los timers de systemd cumplen la misma función básica de ejecutar tareas de forma programada, pero difieren en su enfoque, su complejidad y sus capacidades. cron es la herramienta clásica, sencilla y ligera: cada tarea se define en una sola línea con sus cinco campos de tiempo, lo que lo hace muy rápido de configurar para necesidades simples. Los timers de systemd, en cambio, son la alternativa moderna integrada en el sistema de gestión de servicios que usan la mayoría de las distribuciones actuales, y requieren definir dos elementos separados, uno que describe qué tarea ejecutar y otro que describe cuándo, lo que los hace más verbosos de configurar. A cambio de esa mayor complejidad, los timers aportan varias ventajas importantes. La primera es que cada ejecución queda registrada en el sistema centralizado de registros, lo que permite consultar fácilmente si la tarea se ejecutó, cuándo y con qué resultado, algo que con cron requiere configurar manualmente el registro de la salida. La segunda es la capacidad de recuperar ejecuciones perdidas: si el equipo estaba apagado en el momento en que la tarea debía ejecutarse, un timer configurado de forma persistente la ejecutará en cuanto el sistema vuelva a encenderse, mientras que cron simplemente perdería esa ejecución. La tercera es una mejor integración con el resto de los servicios del sistema, permitiendo establecer dependencias, reintentos y otras condiciones. La regla práctica es usar cron para tareas simples y rápidas, y recurrir a los timers cuando se necesita registro fiable, recuperación de ejecuciones perdidas o coordinación con otros servicios.

La forma correcta de gestionar las tareas programadas de cron para el usuario actual es mediante el comando específico de edición del crontab, que abre el archivo de tareas del usuario en un editor de texto y, muy importante, valida el formato al guardar, evitando que se introduzcan líneas mal formadas que impedirían el funcionamiento. No se debe editar directamente el archivo del crontab en el disco, tanto porque su ubicación puede variar como porque se perdería esa validación; en su lugar, se usa siempre el comando de edición, que se encarga de todo de forma segura. Para consultar las tareas actualmente programadas sin modificarlas, existe otro comando que las lista, mostrando el contenido del crontab del usuario. La primera vez que se edita el crontab, es posible que el sistema pregunte qué editor de texto se desea utilizar. Una vez dentro, se añade o modifica una línea por tarea, respetando el formato de los cinco campos de tiempo seguidos del comando, y al guardar y cerrar el editor los cambios entran en vigor automáticamente sin necesidad de reiniciar nada. Conviene recordar que cada usuario gestiona su propio crontab con estos comandos, y que las tareas se ejecutarán con los permisos de ese usuario; para tareas que requieran privilegios de administrador, se gestiona el crontab correspondiente con los permisos adecuados. Como buena práctica, antes de modificar un crontab con tareas importantes conviene guardar una copia de su contenido listándolo, de modo que se pueda restaurar si algo sale mal.

Sí, y de hecho automatizar copias de seguridad es uno de los usos más habituales y valiosos de cron, precisamente porque las copias de seguridad son una tarea que debe realizarse de forma regular y consistente, y que es fácil olvidar si se depende de hacerla manualmente. El enfoque típico consiste en escribir un script que realice la copia de seguridad, encargándose de comprimir o sincronizar los datos que se quieren proteger hacia un destino seguro, preferiblemente en una ubicación separada del sistema original, y luego programar ese script en cron para que se ejecute automáticamente con la frecuencia deseada, por ejemplo cada noche a una hora de poca actividad. Al hacerlo, conviene tener presentes las buenas prácticas específicas de cron para evitar los fallos habituales: usar rutas absolutas en el script para todo, tanto para los orígenes de datos como para el destino, redirigir la salida a un archivo de registro para poder comprobar que la copia se realizó correctamente y diagnosticar cualquier problema, y asegurarse de que el script tiene permisos de ejecución. Además, es fundamental recordar que una copia de seguridad solo es útil si funciona cuando se necesita, por lo que se recomienda verificar periódicamente que las copias se están generando y que se pueden restaurar realmente, ya que una automatización que falla en silencio da una falsa sensación de seguridad. Para tareas de copia de seguridad en las que sea crítico saber con certeza si se ejecutaron, o recuperar las que se perdieron por apagados del equipo, los timers de systemd con su registro integrado y su capacidad de recuperación pueden ser una opción incluso mejor que cron.