La automatización de tareas es una de las habilidades fundamentales de cualquier administrador de sistemas Linux. Gracias a herramientas como cron, anacron, at y los modernos systemd timers, puedes programar copias de seguridad, rotación de logs, actualizaciones del sistema, envío de informes y prácticamente cualquier tarea repetitiva para que se ejecute sin intervención humana. En esta guía aprenderás a dominar todas estas herramientas con ejemplos prácticos y profesionales.
⏰ Qué es Cron y por qué es esencial
Cron es un demonio (servicio en segundo plano) presente en prácticamente todas las distribuciones Unix y Linux. Su función es sencilla pero poderosa: ejecutar comandos o scripts de forma automática en momentos predefinidos — cada minuto, hora, día, semana o mes, o en cualquier combinación de estos intervalos.
El nombre «cron» proviene del griego chronos (χρόνος), que significa «tiempo». Es uno de los servicios más antiguos y fiables de Unix, presente desde la versión 7 de Unix en 1979. La implementación más extendida en Linux moderno es Vixie Cron, creada por Paul Vixie en 1987, que es la base de las versiones que incluyen Ubuntu, Debian, Fedora y la mayoría de distribuciones actuales.
La automatización con cron es esencial en la administración profesional de sistemas por varias razones:
| Ventaja | Descripción | Ejemplo real |
|---|---|---|
| Fiabilidad | Las tareas se ejecutan siempre a la hora programada, sin olvidos humanos | Backup diario a las 3:00 AM |
| Eficiencia | Tareas pesadas se programan en horas de baja actividad | Regenerar índices de BD a medianoche |
| Consistencia | El mismo proceso se ejecuta exactamente igual cada vez | Rotación de logs cada domingo |
| Escalabilidad | Un administrador gestiona cientos de servidores con tareas automatizadas | Actualización de seguridad en flota |
| Auditoría | Cada ejecución queda registrada en logs del sistema | Histórico de tareas en syslog |
🏗️ Arquitectura del sistema Cron
Para dominar cron es fundamental entender cómo se organiza internamente. El sistema se compone de varios elementos que interactúan entre sí:
El demonio crond
El demonio cron (también llamado crond) se inicia automáticamente con el sistema y permanece activo en segundo plano. Cada minuto, despierta y comprueba si alguna tarea debe ejecutarse en ese instante. Si encuentra una coincidencia, lanza el comando correspondiente en un nuevo proceso shell.
Los archivos crontab
Cada usuario del sistema puede tener su propio archivo crontab (cron table), que se almacena en /var/spool/cron/crontabs/ (Debian/Ubuntu) o /var/spool/cron/ (Red Hat/Fedora). Estos archivos no se editan directamente sino a través del comando crontab.
Directorios del sistema
Además de los crontabs de usuario, el sistema mantiene una estructura de directorios predefinida:
| Ruta | Función | Frecuencia |
|---|---|---|
/etc/crontab | Crontab principal del sistema (incluye campo de usuario) | Definida en cada línea |
/etc/cron.d/ | Crontabs adicionales instalados por paquetes del sistema | Definida en cada línea |
/etc/cron.hourly/ | Scripts ejecutados cada hora | Cada hora |
/etc/cron.daily/ | Scripts ejecutados una vez al día | Diariamente |
/etc/cron.weekly/ | Scripts ejecutados una vez por semana | Semanalmente |
/etc/cron.monthly/ | Scripts ejecutados una vez al mes | Mensualmente |
/etc/cron.daily/, etc.). No necesitas escribir sintaxis crontab: basta con que el archivo sea un script con permisos de ejecución.
📋 Sintaxis de crontab: los 5 campos
La sintaxis de crontab es uno de esos conocimientos que todo administrador Linux debe memorizar. Cada línea de un crontab de usuario sigue este formato:
Descripción detallada de cada campo
| Campo | Rango | Valores especiales | Ejemplo |
|---|---|---|---|
| Minuto | 0–59 | *, */n, n-m, n,m | 30 = minuto 30 |
| Hora | 0–23 | *, */n, n-m, n,m | 14 = 2:00 PM |
| Día del mes | 1–31 | *, */n, n-m, n,m | 1,15 = días 1 y 15 |
| Mes | 1–12 (o jan–dec) | *, */n, n-m, n,m | 6 = junio |
| Día de la semana | 0–7 (o sun–sat) | *, */n, n-m, n,m | 1-5 = lunes a viernes |
Operadores especiales
Los operadores permiten definir patrones complejos de ejecución sin necesidad de enumerar cada valor:
| Operador | Significado | Ejemplo | Resultado |
|---|---|---|---|
* | Cualquier valor | * * * * * | Cada minuto |
, | Lista de valores | 0,30 * * * * | Minutos 0 y 30 |
- | Rango de valores | * 9-17 * * * | De 9:00 a 17:59 |
/ | Paso (cada N) | */10 * * * * | Cada 10 minutos |
0 8 15 * 1 se ejecuta los días 15 de cada mes Y también todos los lunes. Este comportamiento sorprende a muchos administradores.
Atajos especiales de crontab
Muchas implementaciones de cron aceptan cadenas especiales que simplifican la configuración:
| Atajo | Equivalente | Significado |
|---|---|---|
@reboot | — (especial) | Al arrancar el sistema |
@yearly | 0 0 1 1 * | Una vez al año (1 enero, medianoche) |
@monthly | 0 0 1 * * | Una vez al mes (día 1, medianoche) |
@weekly | 0 0 * * 0 | Una vez por semana (domingo, medianoche) |
@daily | 0 0 * * * | Una vez al día (medianoche) |
@hourly | 0 * * * * | Una vez por hora (minuto 0) |
🛠️ Gestión de crontab: crear, editar y listar
El comando crontab es la herramienta principal para gestionar las tareas programadas de un usuario. Nunca debes editar directamente los archivos en /var/spool/cron/; el comando crontab se encarga de validar la sintaxis y notificar al demonio cron de los cambios.
crontab -e se abre un editor que no te resulta familiar (como nano o vi), puedes cambiar el editor predeterminado con: export EDITOR=nano (o vim, code, etc.). Para hacerlo permanente, añade esa línea a tu ~/.bashrc.
Instalar un crontab desde archivo
Una práctica profesional es mantener tus crontabs en archivos de texto versionados con Git. Puedes instalar un crontab directamente desde un archivo:
crontab archivo.txt reemplaza completamente tu crontab actual. No añade las líneas al final. Si quieres añadir tareas sin perder las existentes, exporta primero con crontab -l > mi_crontab.txt, edita el archivo y luego reinstala.
🎯 Ejemplos prácticos de tareas programadas
Veamos una colección de ejemplos reales que cubren los escenarios más comunes en la administración de sistemas:
Tareas de mantenimiento del sistema
Tareas de monitorización
Tareas de desarrollo y base de datos
% tiene un significado especial: se interpreta como salto de línea. Si necesitas usarlo (por ejemplo, con date +%Y%m%d), debes escaparlo con barra invertida: date +\%Y\%m\%d. Este es uno de los errores más frecuentes en tareas cron que nunca se ejecutan.
🔧 Variables de entorno en crontab
Uno de los errores más comunes al trabajar con cron es asumir que las tareas se ejecutan con el mismo entorno que tu sesión de terminal. No es así. Cron ejecuta cada tarea con un entorno mínimo y restringido.
| Variable | Valor por defecto en cron | Recomendación |
|---|---|---|
SHELL | /bin/sh | Definir /bin/bash si usas bashisms |
PATH | /usr/bin:/bin | Definir PATH completo o usar rutas absolutas |
HOME | Home del usuario | Generalmente correcto, ajustar si es necesario |
MAILTO | Usuario propietario del crontab | Definir email o vacío para no enviar |
LANG | No definido | Definir si el script maneja texto con acentos |
comando > /dev/null 2>&1. Para silenciar todas: MAILTO="".
📂 El crontab del sistema: /etc/crontab y cron.d
Además de los crontabs personales de cada usuario, existe un crontab del sistema en /etc/crontab. Este archivo tiene una diferencia crucial: incluye un campo adicional para especificar con qué usuario se ejecuta cada tarea.
Observa la lógica: si anacron está instalado, las tareas diarias, semanales y mensuales las gestiona anacron (que garantiza su ejecución aunque el sistema se apague). Si anacron no está disponible, run-parts ejecuta los scripts directamente.
El directorio /etc/cron.d/
El directorio /etc/cron.d/ contiene archivos crontab adicionales, normalmente instalados por paquetes del sistema. Cada archivo sigue la misma sintaxis que /etc/crontab (con campo de usuario). Es la forma recomendada de añadir tareas de sistema sin modificar /etc/crontab directamente.
sleep aleatorio antes de ejecutarse. Esto evita que miles de servidores renueven sus certificados simultáneamente, distribuyendo la carga sobre los servidores de Let's Encrypt. Es una buena práctica conocida como jitter (dispersión temporal).
🔄 Anacron: tareas para equipos que se apagan
Anacron resuelve una limitación fundamental de cron: si el equipo está apagado en el momento programado, cron simplemente no ejecuta la tarea y no hay recuperación. Anacron, en cambio, registra cuándo se ejecutó cada tarea por última vez y, al arrancar el sistema, ejecuta las tareas pendientes.
El campo de retardo es importante: indica cuántos minutos esperar después del arranque antes de ejecutar la tarea. Esto evita que todas las tareas pendientes se lancen simultáneamente al encender el equipo, lo que podría saturar los recursos.
| Característica | Cron | Anacron |
|---|---|---|
| Precisión | Al minuto exacto | Solo diario o superior |
| Si el equipo está apagado | Pierde la tarea | La ejecuta al arrancar |
| Ejecución concurrente | Puede ejecutar múltiples en paralelo | Secuencial, una tras otra |
| Ideal para | Servidores 24/7 | Portátiles y estaciones de trabajo |
| Demonio permanente | Sí | No, se ejecuta una vez y termina |
🎯 El comando at: ejecución única programada
Mientras cron es ideal para tareas recurrentes, el comando at sirve para programar la ejecución de un comando una única vez en un momento futuro específico.
at es ideal para situaciones como: «Necesito reiniciar el servidor esta noche a las 3:00 AM después de aplicar un parche», o «Quiero enviar un recordatorio por email dentro de 4 horas». Cuando necesitas programar algo puntual sin modificar tu crontab.
⚡ Systemd timers: la alternativa moderna
En distribuciones modernas con systemd (Ubuntu 16.04+, Debian 8+, Fedora, CentOS 7+), existe una alternativa a cron cada vez más popular: los systemd timers. Son unidades systemd que activan otros servicios en momentos específicos.
¿Por qué considerar systemd timers?
| Ventaja | Cron | Systemd timers |
|---|---|---|
| Logs | Email o redirección manual | Integrado en journalctl |
| Dependencias | No soporta | After=, Requires=, etc. |
| Precisión | 1 minuto | Microsegundos |
| Ejecución perdida | Se pierde (sin anacron) | Persistent=true |
| Aleatorización | Manual con sleep | RandomizedDelaySec= |
| Monitorización | Scripts personalizados | systemctl list-timers |
| Complejidad | Una línea | Dos archivos (.service + .timer) |
Crear un timer paso a paso
Un systemd timer requiere dos archivos: una unidad de servicio (.service) que define qué ejecutar, y una unidad de timer (.timer) que define cuándo ejecutarlo.
🔒 Seguridad y control de acceso en Cron
Cron implementa un sistema de control de acceso basado en dos archivos: /etc/cron.allow y /etc/cron.deny. Estos archivos determinan qué usuarios pueden utilizar el comando crontab.
| Escenario | cron.allow | cron.deny | Resultado |
|---|---|---|---|
| Existe cron.allow | Usuario listado | Se ignora | Puede usar cron |
| Existe cron.allow | Usuario NO listado | Se ignora | No puede usar cron |
| No existe cron.allow | — | Usuario listado | No puede usar cron |
| No existe cron.allow | — | Usuario NO listado | Puede usar cron |
| No existe ninguno | — | — | Solo root (Debian) / Todos (Red Hat) |
for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -l -u $user 2>/dev/null; done. Un atacante que obtenga acceso limitado podría añadir tareas cron para mantener persistencia en el sistema.
🔍 Depuración y solución de problemas
Cuando una tarea cron no funciona como esperas, sigue esta metodología de diagnóstico:
1. Verificar que cron está activo
2. Revisar los logs
3. Probar el script manualmente
Checklist de errores comunes
| Problema | Causa | Solución |
|---|---|---|
| La tarea no se ejecuta | Rutas relativas en el comando | Usar siempre rutas absolutas |
| La tarea no se ejecuta | Script sin permisos de ejecución | chmod +x script.sh |
| Error en la salida | Variables de entorno ausentes | Definir PATH, HOME, SHELL en crontab |
| % causa error de sintaxis | % no escapado en crontab | Escapar con \% |
| Solo funciona interactivamente | El script depende de ~/.bashrc | Hacer el script autocontenido |
| No genera salida esperada | Redirección incorrecta | Usar >> log 2>&1 |
* * * * * env > /tmp/cron_env.txt 2>&1. Revisa el archivo generado para ver exactamente qué variables tiene cron. Compáralo con tu entorno normal (env > /tmp/mi_env.txt) y encontrarás las diferencias que causan el problema.
✅ Buenas prácticas profesionales
Tras años de experiencia con cron en entornos de producción, estas son las prácticas que distinguen a un administrador profesional:
1. Siempre redirige la salida
Cada tarea cron debe tener su salida redirigida a un archivo de log o a /dev/null. Sin redirección, cron intenta enviar la salida por email, lo que puede saturar el buzón del usuario root o, si el sistema de correo no está configurado, los mensajes se acumulan silenciosamente.
2. Usa scripts, no comandos largos
Si tu tarea requiere más de un comando, crea un script aparte y llama al script desde crontab. Esto facilita la depuración, el versionado con Git y las pruebas manuales.
3. Implementa bloqueo contra ejecución concurrente
Si una tarea tarda más de lo esperado y se solapa con la siguiente ejecución, puedes tener problemas graves. Usa flock para evitarlo:
4. Documenta cada tarea
Añade un comentario descriptivo antes de cada línea en tu crontab. Tu futuro yo (o quien te reemplace) lo agradecerá:
5. Versiona tus crontabs con Git
Mantén un repositorio con los crontabs de tus servidores. Ante cualquier problema, puedes restaurar la configuración anterior en segundos.
📝 Ejercicios prácticos
Pon a prueba tus conocimientos con estos ejercicios progresivos:
Ejercicio 1: Tu primer cron job
Crea una tarea cron que registre la fecha y hora actual en un archivo cada 2 minutos.
Ejercicio 2: Script de backup con cron
Crea un script que haga una copia comprimida del directorio /etc/ y prográmalo para ejecutarse cada noche a las 2:00 AM.
Ejercicio 3: Monitorización con alerta
Crea un script que compruebe si el uso de disco supera el 90% y envíe una alerta. Prográmalo cada 30 minutos.
Ejercicio 4: Reto avanzado — Systemd timer
Convierte el backup del ejercicio 2 en un systemd timer que se ejecute a las 2:30 AM con persistencia (si el equipo está apagado, se ejecuta al arrancar) y un retardo aleatorio de hasta 5 minutos.
❓ Preguntas frecuentes sobre Automatización de tareas con Cron en Linux: guía completa
Las dudas más comunes respondidas de forma clara y directa.
💬 Foro de discusión
¿Tienes dudas sobre Automatización de tareas con Cron en Linux: guía completa? Comparte tu pregunta con la comunidad.
Todavía no hay mensajes. ¡Sé el primero en participar!
🎓 ¿Se puede aprender Linux con un curso bonificado por FUNDAE?
Sí. La administración de sistemas y servidores Linux es formación 100 % bonificable por FUNDAE para trabajadores de empresas españolas. Ciberaula, centro acreditado desde 1997, la imparte con tutor personal.
Administración de Servidores Linux para Empresas: de Cero a Nivel Avanzado (40 h) →
También te puede encajar: Administración de Sistemas Linux y Shell Script para Empresas → · Bash Scripting y Terminal Linux: Automatización de Sistemas →
Ver todos los cursos de Linux bonificados del catálogo → · Ciberaula · Centro acreditado FUNDAE (Reg. 99000171) · 91 530 33 87 · admision@ciberaula.com