Cómo programar tareas con fcron y cron en Linux

Si te dedicas a administrar sistemas Linux o tienes un servidor casero siempre encendido, tarde o temprano te planteas cómo automatizar tareas de mantenimiento, copias de seguridad y scripts sin estar pendiente del reloj. Ahí es donde entra en juego fcron: un programador de tareas que va un paso más allá de cron y se adapta mucho mejor a equipos que no están encendidos 24/7.

A lo largo de este artículo vas a ver, con bastante detalle, cómo programar tareas con fcron, qué diferencia a este demonio de cron y anacron, cómo se integra con syslog, qué ficheros de configuración intervienen, cómo usar fcrontab para definir trabajos y qué problemas típicos te puedes encontrar al automatizar procesos en GNU/Linux. La idea es que termines con una visión muy completa, tanto de fcron como del ecosistema cron clásico, para que puedas elegir y configurar la solución que más te convenga.

Qué es fcron y en qué se diferencia de cron y anacron

fcron es un demonio de planificación de tareas pensado para sistemas que no necesariamente permanecen encendidos todo el tiempo. Viene a cubrir el hueco entre cron (que asume que la máquina está siempre activa) y anacron (centrado en tareas diarias, semanales, mensuales sin dependencia de la hora exacta).

Mientras que cron revisa cada minuto si debe lanzar algo en función de la hora del sistema, como se explica en programar tareas en Linux con cron y at, fcron es capaz de ejecutar trabajos “pendientes” que no se han podido lanzar porque el equipo estaba apagado. De este modo, si programas una tarea para todos los días a las 03:00 y el equipo se enciende a las 09:00, fcron puede decidir correr ese job en cuanto arranque, según la configuración que le hayas dado.

Otra diferencia importante es que fcron permite expresiones de planificación mucho más flexibles, con opciones como “cada X tiempo de uptime”, límites de concurrencia, prioridades, o condiciones más ricas que las que ofrece el cron clásico. Además, se integra con syslog usando la facilidad cron, por lo que todo su registro de actividad queda centralizado en los logs del sistema.

Como otros programas de este tipo, fcron se compone de un demonio principal (fcron) y de una utilidad para gestionar las tablas de tareas, llamada fcrontab, que es el equivalente directo al comando crontab de toda la vida pero con sintaxis y opciones añadidas.

Archivos de configuración y control de acceso en fcron

Al instalar fcron, aparecen varios ficheros clave en el sistema que conviene conocer. Los más importantes son /etc/fcron.conf, /etc/fcron.allow y /etc/fcron.deny, que controlan el comportamiento general del demonio y quién puede programar tareas.

El archivo /etc/fcron.conf define la configuración global del demonio fcron: opciones de entorno, rutas, comportamiento por defecto y parámetros que afectan a cómo se gestionan los trabajos. Aunque en la mayoría de instalaciones básicas no es necesario tocar este fichero, es recomendable leer su página de manual (man fcron.conf) para conocer todas las posibilidades, sobre todo si vas a exprimir las características avanzadas.

Para el control de acceso de usuarios, fcron utiliza los archivos /etc/fcron.allow y /etc/fcron.deny, de forma muy similar a cron. En fcron.allow puedes listar explícitamente los usuarios a los que quieres permitir el uso de fcrontab, mientras que en fcron.deny puedes indicar una “lista negra” de usuarios a los que se les bloquea el acceso. Si existe fcron.allow, éste tiene prioridad y se ignora fcron.deny; si no existe ninguno, el comportamiento por defecto suele ser permitir el uso de fcron a todos o sólo a root, según la distribución.

Además de estos archivos, el demonio se integra con el sistema de arranque mediante un script de inicio, habitualmente en /etc/rc.d/init.d/fcron o ubicaciones equivalentes según la distro. Este script suele llegar a tu sistema a través de paquetes como los blfs-bootscripts, que proporcionan los guiones necesarios para activar servicios al arrancar.

Instalación y preparación del sistema para usar fcron

Antes de ponerte a programar tareas, necesitas tener el servicio correctamente instalado y bien integrado con el registro de logs y el sistema de usuarios. Aquí entra en juego la configuración de syslog, la creación de un usuario dedicado y el propio proceso de compilación/instalación de fcron si vienes desde código fuente.

Por defecto, fcron utiliza la facilidad cron de syslog para escribir todos sus mensajes. En sistemas donde el fichero /etc/syslog.conf no define ninguna entrada para esa facilidad (algo habitual en ciertos entornos como LFS o BLFS), es necesario añadir una línea para que los mensajes se guarden en un log separado. Una forma típica de hacerlo es apendizar:

cron.* -/var/log/cron.log

Con esto, todos los mensajes etiquetados como cron (incluidos los de fcron) se almacenarán en /var/log/cron.log. Tras modificar syslog.conf, es imprescindible recargar el demonio de logging (por ejemplo, sysklogd) para que la nueva configuración surta efecto, usando un comando tipo:

/etc/rc.d/init.d/sysklogd reload

Desde el punto de vista de seguridad, es buena práctica que fcron corra bajo un usuario y grupo sin privilegios. Lo habitual es crear una cuenta de sistema específica, por ejemplo:

Crear usuario y grupo de servicio: groupadd fcron && useradd -c fcron -g fcron fcron

Una vez preparado el entorno de logs y el usuario de servicio, puedes proceder a compilar e instalar fcron desde las fuentes si tu distribución no ofrece un paquete precompilado adecuado. Un flujo bastante habitual consiste en ejecutar:

Compilar e instalar desde fuentes: ./configure --without-sendmail --with-answer-all=no && make && make install

La opción –without-sendmail indica que fcron no utilizará un MTA (Mail Transfer Agent) para enviar correos con la salida de los trabajos, aunque es perfectamente capaz de integrarse con uno si lo tienes instalado. Si te interesa recibir notificaciones por correo, puedes usar algo como --with-sendmail=/ruta/a/tu/MTA en el configure, apuntando al binario real de tu servidor de correo.

El parámetro –with-answer-all=no controla el comportamiento de la rutina de configuración que se ejecuta durante make install. Parte de ese proceso suele preguntar si quieres instalar un script de arranque bajo /etc/rc.d/init.d y crear automáticamente los enlaces simbólicos en los niveles de ejecución 2, 3, 4 y 5, además de parar cualquier instancia de fcron y levantar una nueva. Si es tu primera instalación y prefieres usar un script de inicio que siga la plantilla estándar de tu sistema (por ejemplo, los scripts de BLFS), lo normal es responder “n” a esas preguntas, tal y como sugiere la documentación.

Si tienes OpenJade y las DSSSL stylesheets instaladas, puedes añadir una opción adicional al configure, del tipo --with-dsssl-dir=/usr/share/sgml/docbook/dsssl-stylesheets-1.78, para que se genere documentación a partir de las fuentes en DocBook. No es obligatorio para ejecutar fcron, pero puede resultar útil si quieres tener la documentación en formatos adicionales.

Uso de fcrontab para programar tareas con fcron

La herramienta principal para definir y modificar las tareas de fcron es fcrontab. Funciona de forma similar al crontab tradicional, pero con extensiones específicas y la sintaxis propia de fcron. Cada usuario puede tener su propia tabla de trabajos, y existe también un fcrontab de sistema que suele estar en /etc/fcrontab.

Cuando modificas el archivo de tareas del sistema, es necesario recargarlo explícitamente para que fcron lea los cambios. En el caso del fcrontab global, tras editar /etc/fcrontab tendrás que ejecutar algo como:

Recargar fcrontab: fcrontab /etc/fcrontab

Esto carga el contenido de ese fichero en la tabla interna que maneja el demonio. La página de manual de fcrontab detalla todas las opciones, pero el patrón de uso básico es parecido al de cron. Para el fcrontab propio de un usuario (incluido root) basta con lanzar:

fcrontab -e

Al igual que con crontab, se abrirá el editor de texto configurado por defecto (vi, nano, etc.) y podrás añadir o modificar las líneas que definen tus trabajos. Cada entrada describe cuándo y cómo se ejecutará un comando o script, y fcron se encarga de correrlo aunque no haya ninguna sesión de login activa. Es decir, la presencia o ausencia de usuarios interactivos en el sistema es irrelevante: los jobs de fcron se ejecutan igualmente en segundo plano.

Además de fcrontab, fcron proporciona la utilidad fcronsighup, cuya función es enviar una señal al demonio para que vuelva a leer las tablas de tareas sin necesidad de reiniciar el servicio. Es especialmente útil tras modificaciones frecuentes de la configuración o si administras fcron en sistemas con muchas tareas programadas.

Programar tareas con cron y crontab: fundamentos y sintaxis

Aunque fcron ofrece muchas ventajas, sigue siendo fundamental entender cómo funciona el cron clásico y su fichero crontab, porque buena parte de los conceptos se comparten y muchas distribuciones lo traen activado por defecto nada más instalar el sistema.

Cron es un demonio que se ejecuta en segundo plano desde el arranque del sistema operativo. Cada minuto comprueba si en los ficheros de planificación (como /etc/crontab o los crontabs de usuario en /var/spool/cron/crontabs) hay alguna tarea cuyo momento de ejecución coincida con la hora actual del sistema. De ahí la importancia de tener bien configurada la hora y la zona horaria.

Para verificar la configuración horaria en sistemas actuales, es habitual usar timedatectl, que muestra la hora local, hora universal, zona horaria y si el reloj está sincronizado con servidores NTP. Si detectas que la zona no es correcta, puedes ajustarla con un comando del estilo:

Ajustar zona horaria: timedatectl set-timezone Europe/Madrid

En cuanto al formato de crontab, cada línea que define una tarea sigue la estructura clásica de cinco campos de tiempo más el comando. Cada asterisco o valor indica una parte concreta de la fecha:

• Minuto: de 0 a 59.
• Hora: de 0 a 23.
• Día del mes: de 1 a 31.
• Mes: de 1 a 12.
• Día de la semana: de 0 a 6, donde 0 (y a veces 7) representa el domingo.
• Comando: la orden o script que quieres lanzar.

Ejemplo diario: 00 19 * * * usuario /ruta/al/script/consulta.sh

Ejemplo domingo: 00 19 * * 0 usuario /ruta/al/script/consulta.sh

Ejemplo anual: 00 19 4 2 * usuario /ruta/al/script/consulta.sh

La sintaxis admite también caracteres especiales que permiten reglas muy potentes: el asterisco para “cualquier valor”, la coma para listados, el guion para rangos (por ejemplo 1-5, de lunes a viernes), la barra para indicar periodicidades (*/10 para “cada 10 unidades”) y combinaciones tipo “rango/excepción” para excluir ciertos valores concretos.

Crontab del sistema y directorios cron.* en Linux

En muchas distribuciones, especialmente en entornos como Debian, cron se organiza en torno a un crontab de sistema en /etc/crontab y a varios directorios especiales bajo /etc/ donde se pueden dejar scripts para que se ejecuten con distinta periodicidad predefinida.

El fichero /etc/crontab suele incluir entradas que disparan el comando run-parts apuntando a directorios como /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly y /etc/cron.monthly. La idea es que cualquier script que coloques allí (y que cumpla ciertas condiciones de permisos y nombre) se ejecutará automáticamente con la cadencia indicada, sin que tengas que escribir a mano todas las líneas.

Ejemplo típico de /etc/crontab: 17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Estas líneas hacen que cada hora, cada día, cada semana y cada mes se ejecuten todos los scripts presentes en los directorios indicados, usando la herramienta run-parts, que se encarga de llamar en cadena a todos los ficheros ejecutables que cumplan cierto patrón de nombre.

Para que cron ejecute esos scripts sin poner pegas, deben cumplirse varias condiciones: tener permiso de ejecución, pertenecer a root, que grupo y otros no tengan permiso de escritura, y que el nombre sólo contenga letras, dígitos, guion bajo o guion normal. Si el nombre lleva otros caracteres, cron simplemente lo ignorará.

Además, existe el directorio /etc/cron.d, destinado a que las aplicaciones de sistema dejen ahí sus propios ficheros crontab con reglas específicas que no encajan en los cuatro directorios anteriores. Debian recomienda que el administrador principal ponga sus reglas globales en /etc/crontab y deje /etc/cron.d para paquetes y servicios que se instalan después.

Control de acceso a cron: cron.allow y cron.deny

Al igual que fcron, el cron clásico permite restringir qué usuarios pueden crear trabajos programados mediante dos ficheros muy sencillos: /etc/cron.allow y /etc/cron.deny. El primero actúa como lista blanca y el segundo como lista negra.

Si creas /etc/cron.allow y añades uno o varios nombres de usuario, solo esos usuarios tendrán derecho a usar crontab y definir sus propias tareas, quedando el resto automáticamente bloqueados. Si prefieres lo contrario, es decir, permitir a todos salvo a unos pocos, puedes mantener /etc/cron.allow vacío o inexistente y usar /etc/cron.deny para listar únicamente los usuarios vetados.

Comportamiento por defecto: En algunos sistemas, si ninguno de estos ficheros existe, se permite a cualquier usuario acceder a cron; en otros, sin embargo, sólo root tiene ese privilegio por defecto. Conviene revisar la documentación de tu distribución para no llevarte sorpresas.

Este mismo patrón se replica con fcron a través de /etc/fcron.allow y /etc/fcron.deny, de forma que puedes unificar tu política de seguridad para ambos demonios y decidir con precisión quién puede programar qué.

Logs y depuración de tareas programadas

Cron y fcron generan mensajes que son vitales para diagnosticar problemas, comprobar ejecuciones y detectar errores. En muchos sistemas, los eventos relacionados con cron se vuelcan en /var/log/syslog o en un archivo específico como /var/log/cron.log, en función de cómo esté configurado syslog o rsyslog.

En el caso concreto del cron de Debian, también es posible ajustar qué tipo de eventos se registran en los logs mediante opciones extras en /etc/default/cron. Allí se puede añadir una línea del estilo:

EXTRA_OPTS='-L 5'

El parámetro -L acepta un valor numérico que es la suma de varios flags: 1 para registrar el inicio de una tarea, 2 para el final, 4 para los trabajos que terminan con código de error distinto de cero y 8 para registrar el PID de cada proceso lanzado. Un valor de 5, por ejemplo, combina 1 y 4, de modo que sólo se registra el comienzo de los jobs y aquellos que fallan, reduciendo el ruido en los logs.

Fcron, al usar la facilidad cron dentro de syslog, se beneficia de la misma configuración: una vez que has definido en /etc/syslog.conf que cron.* se dirija a un log concreto, todo lo que haga fcron también quedará reflejado allí, lo cual es muy cómodo cuando estás afinando una programación complicada.

Impacto en el rendimiento y buenas prácticas al programar tareas

Automatizar procesos es una maravilla, pero un uso poco cuidadoso de cron o fcron puede tener efectos muy negativos en el rendimiento del sistema. Es fácil caer en la tentación de disparar scripts muy pesados con demasiada frecuencia, con el resultado de picos de CPU, fuertes accesos a disco o saturación de la red.

Ejemplo de carga: Cuando concentras varias tareas exigentes en la misma franja horaria, puedes provocar que se lancen todas a la vez y el equipo se resienta. Por ejemplo, hacer copias de seguridad voluminosas, rotar logs de muchos servicios y actualizar grandes bases de datos justo a medianoche puede ser una mala idea si el servidor también atiende peticiones críticas en ese momento.

Para mitigar estos problemas, es recomendable escalonar las tareas y aprovechar horas de baja carga, como la madrugada. También puedes introducir aleatoriedad o condicionantes en los scripts, de forma que se ejecuten sólo si el sistema está lo suficientemente holgado (bajo uso de CPU, disco o red).

Prioridad y límites: Herramientas como nice o cpulimit son muy útiles: puedes lanzar tus scripts con prioridad baja o limitar el porcentaje máximo de CPU que consumen. De esta manera, aunque se ejecuten en momentos críticos, tendrán menos impacto sobre otros procesos.

Evitar solapamientos: En sistemas donde un mismo job pueda solaparse consigo mismo, conviene usar utilidades como flock para impedir ejecuciones concurrentes. Un patrón habitual es envolver el script en un bloqueo de fichero: si el lock ya está tomado, el nuevo intento de cron o fcron simplemente sale sin hacer nada, evitando conflictos en accesos simultáneos a los mismos recursos.

Errores típicos al usar cron y fcron y cómo evitarlos

Al empezar a programar tareas, es frecuente encontrarse con situaciones en las que los scripts “no se ejecutan” o parecen hacerlo de forma errática. Muchas veces, el problema no está en cron ni en fcron, sino en detalles de entorno, permisos o rutas.

Uno de los errores más habituales es asumir que el entorno de ejecución de cron o fcron es el mismo que el de tu sesión interactiva. En realidad, estos demonios lanzan los comandos en un entorno muy minimalista, con un PATH limitado. Si tu script llama a binarios como git, python o cualquier programa instalado en rutas no estándar, y no especificas la ruta completa, es probable que falle.

Usar rutas absolutas: La solución pasa por usar rutas absolutas dentro de los scripts (por ejemplo, /usr/bin/python en vez de python) o definir explícitamente la variable PATH al inicio del crontab o fcrontab, con algo tipo:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Revisa permisos: Otra fuente de problemas son los permisos de ejecución. Si el fichero no es ejecutable o el usuario bajo el que corre la tarea no tiene permisos suficientes sobre directorios y recursos implicados, el job fallará silenciosamente o sólo dejará rastro en logs. Revisa con ls -l y corrige con chmod +x cuando sea necesario, y piensa si tu script realmente necesita privilegios de root o basta con un usuario normal.

Es muy recomendable que, durante las pruebas, redirijas stdout y stderr a ficheros dentro de tus entradas de cron o fcron, de modo que puedas inspeccionar qué ha ocurrido. Una construcción como >/ruta/log.txt 2>&1 al final de la línea de crontab te puede ahorrar horas de frustración.

Por último, recuerda que el comportamiento frente a cambios de hora (horario de verano/invierno) no siempre es trivial. Cron intenta gestionar los saltos de menos de tres horas de la mejor manera posible, pero si tus tareas dependen con mucha precisión del orden y del tiempo transcurrido entre ejecuciones, puede ser prudente evitar la franja conflictiva o diseñar reglas especiales para esas noches de cambio horario.

Dominar cron, fcron y sus pequeñas particularidades te permite construir una capa de automatización muy potente sobre cualquier sistema Linux, combinando la sencillez de las expresiones de tiempo con todo el potencial de los scripts y herramientas de consola para mantener, monitorizar y optimizar tus servidores sin tener que estar pendiente de ellos a todas horas.