El comando crontab programa tareas periódicas en sistemas Linux mediante el demonio cron. Para definir ejecuciones automáticas, el usuario edita su tabla personal con crontab -e, especifica los cinco campos temporales y declara la ruta absoluta del ejecutable, evitando que un entorno mínimo sin las variables habituales interrumpa la ejecución silenciosamente.
La sintaxis de los cinco campos en crontab -e
El archivo de configuración de cron procesa líneas con cinco parámetros temporales seguidos de la orden que debe invocar el sistema operativo. La sintaxis exacta se organiza de izquierda a derecha: minuto (0-59), hora (0-23), día del mes (1-31), mes (1-12) y día de la semana (0-7, donde tanto 0 como 7 representan el domingo).
Para modificar estas instrucciones en la cuenta del usuario actual, el comando estándar abre el editor predeterminado del sistema:
crontab -eDentro del archivo, los asteriscos representan cualquier valor posible, las comas separan listas discretas, los guiones indican rangos continuos y la barra inclinada define saltos periódicos. Si editas este archivo desde una pantalla táctil, interfaces como el teclado integrado de termi1 para iOS y Android facilitan la navegación con teclas directas como Esc, Ctrl, flechas de cursor y Tabulación al interactuar con editores como nano o Vim en conexiones remotas.
# Ejecutar un script de limpieza de lunes a viernes a las 03:30
30 3 * * 1-5 /usr/local/bin/backup-cleanup.sh
# Ejecutar una comprobación cada 15 minutos todos los días
*/15 * * * * /usr/bin/curl -fsS https://ejemplo.com/healthcheckEl problema del PATH mínimo y cómo definir variables en crontab
El demonio cron no inicializa las variables de entorno interactivas que definen archivos como ~/.bashrc o /etc/profile. En la mayoría de distribuciones Linux, la variable PATH predeterminada bajo cron se reduce estrictamente a /usr/bin:/bin, lo que provoca fallos cuando un script invoca binarios ubicados en /usr/local/bin, directorios de usuario o entornos virtuales.
Existen dos formas canónicas de solucionar discrepancias en el entorno:
- Declarar rutas absolutas en cada invocación, llamando directamente a
/usr/local/bin/nodeo/usr/bin/python3en lugar del nombre aislado de la herramienta. - Sobrescribir la variable PATH en la cabecera del propio archivo crontab antes de listar las directivas programadas.
- Establecer el intérprete explícito asignando la directiva
SHELL=/bin/bashpara evitar inconsistencias con/bin/sh.
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 2 * * * backup-database --allRedirigir stdout y stderr para depurar scripts en crontab
El demonio cron intenta enviar cualquier salida generada por un comando al correo local del usuario mediante el servicio de correo del sistema (MTA). Si el servidor no dispone de un agente de transporte como Postfix configurado, los mensajes de error y las confirmaciones se descartan sin dejar rastro visible en la terminal.
Para capturar incidencias y comprobar el resultado de la ejecución, es imprescindible redirigir la salida estándar (descriptor 1) y la salida de error (descriptor 2) hacia un archivo de registro específico en disco:
0 4 * * * /usr/local/bin/sync-storage.sh >> /var/log/sync-storage.log 2>&1La sintaxis >> añade el texto al final del archivo sin sobrescribir el historial previo, mientras que la construcción 2>&1 fusiona los mensajes de error con el flujo ordinario. Al administrar servidores desde el móvil, puedes revisar inmediatamente este fichero descargándolo o abriéndolo mediante el cliente SFTP integrado en tu aplicación de terminal sin necesidad de abrir una segunda sesión paralela ni alterar tu sesión activa.
Comprobar la ejecución del demonio con journalctl -u cron
El registro del sistema almacena cada intento de inicio de tarea programada mediante systemd. En distribuciones basadas en Debian y Ubuntu el servicio se denomina cron, mientras que en sistemas basados en RHEL o Fedora utiliza el nombre crond.
Para auditar si el temporizador ejecutó la instrucción a la hora requerida, consulta el registro unificado con systemd:
# En Debian, Ubuntu y derivados
journalctl -u cron -n 50 --no-pager
# En RHEL, Rocky Linux y Fedora
journalctl -u crond -n 50 --no-pagerPara seguir los lanzamientos en tiempo real mientras realizas pruebas de periodicidad inmediata, añade el modificador de seguimiento continuo:
journalctl -u cron -fSi experimentas cortes de conectividad mientras monitorizas registros desde una red móvil inestable, mantener la conexión remota bajo el protocolo Mosh previene la congelación de la pantalla frente a pérdidas de paquetes o cambios de antena.
Inspección de tareas cron: terminal móvil frente a cliente de escritorio
La administración remota de temporizadores requiere herramientas que adapten la interacción con shells Unix según el contexto del administrador:
| Operación | Escritorio convencional | Terminal móvil |
|---|---|---|
| Edición en nano/vi | Uso de teclado físico estándar | Requiere teclas auxiliares como Esc y Ctrl |
| Persistencia de sesión | Suele depender de multiplexores manuales | Mosh y tmux mantienen la sesión viva |
| Auditoría de logs | Terminal en ventana secundaria | Cambio entre pestañas o visor SFTP directo |
| Entrada de órdenes | Escritura completa manual | IA con modo seguro para evitar ejecuciones involuntarias |
Para entornos sin IP pública donde debas revisar registros de cron, puedes combinar tu cliente con redes privadas en malla como Prialo para acceder a los nodos internos de forma directa y cifrada.
Preguntas frecuentes
¿Por qué crontab no ejecuta un comando que funciona en la terminal interactiva?
crontab utiliza un entorno de ejecución restringido sin las variables que exporta tu shell interactiva. Si tu comando depende de binarios fuera de los directorios estándar o variables definidas en .bashrc, fallará de inmediato a menos que declares el PATH completo o uses rutas absolutas para cada ejecutable.
¿Cómo puedo listar las tareas programadas activas sin abrirlas para edición?
El comando crontab -l imprime el contenido completo de la tabla del usuario actual en la salida estándar. Para consultar los trabajos programados de otro usuario con privilegios administrativos, utiliza crontab -u nombre_usuario -l desde una cuenta autorizada con sudo.
¿Qué significa el carácter especial @reboot en una línea de crontab?
La directiva @reboot sustituye a los cinco campos numéricos temporales tradicionales. Indica al demonio cron que debe invocar el comando o script designado exactamente una vez tras el arranque del sistema operativo, antes de iniciar la monitorización ordinaria por minutos y horas.
¿Dónde almacena Linux los registros de cron si no uso systemd?
En distribuciones Linux que emplean demonios de registro tradicionales como rsyslog sin journald activo, los eventos de cron se almacenan habitualmente en el archivo /var/log/syslog en distribuciones Debian y Ubuntu, o en /var/log/cron en sistemas de la familia Red Hat.