cron

Algunas implementaciones de cron ^{[ 8 ]} admiten las siguientes macros no estándar:

@rebootConfigura una tarea para que se ejecute una sola vez al iniciar el demonio. Dado que cron normalmente nunca se reinicia, esto suele coincidir con el arranque de la máquina. Este comportamiento se aplica en algunas variantes de cron, como la que se incluye en Debian [ ^{9 ], de} modo que reiniciar el demonio no vuelva a ejecutar @rebootlas tareas.

@rebootPuede resultar útil si es necesario iniciar un servidor o demonio bajo un usuario específico, y dicho usuario no tiene acceso para configurar init e iniciar el programa.

Estos dos archivos desempeñan un papel importante:

• /etc/cron.allow – Si este archivo existe, debe contener el nombre del usuario para que este pueda usar las tareas programadas (cron jobs).
• /etc/cron.deny – Si el archivo cron.allow no existe pero el archivo /etc/cron.deny sí existe, entonces, para usar trabajos cron, los usuarios no deben estar listados en el archivo /etc/cron.deny.

Tenga en cuenta que si ninguno de estos archivos existe, dependiendo de los parámetros de configuración específicos del sitio, solo el superusuario podrá usar las tareas programadas (cron jobs) o todos los usuarios podrán usarlas.

La mayoría de las implementaciones de cron simplemente interpretan las entradas de crontab en la configuración de zona horaria del sistema bajo la cual se ejecuta el demonio cron. Esto puede ser motivo de controversia si una máquina multiusuario grande tiene usuarios en varias zonas horarias, especialmente si la zona horaria predeterminada del sistema incluye el horario de verano, que puede resultar confuso . Por lo tanto, una implementación de cron puede, como caso especial, reconocer líneas del tipo "CRON_TZ= < zona horaria > " en los crontabs de los usuarios, interpretando las entradas de crontab subsiguientes en relación con esa zona horaria. ^{[ 10 ]}

En la versión 7 de Unix, el cron era un servicio del sistema (más tarde llamado demonio ) que se invocaba /etc/rccuando el sistema operativo entraba en modo multiusuario. ^{[ 11 ]} Su algoritmo era sencillo:

1. Leer /usr/lib/crontab^{[ 12 ]}
2. Determina si algún comando debe ejecutarse en la fecha y hora actuales y, de ser así, ejecútalo como superusuario , root.
3. Duerme un minuto
4. Repita desde el paso 1.

Esta versión de cron era básica y robusta, pero también consumía recursos, independientemente de si encontraba trabajo que hacer o no. En un experimento realizado en la Universidad de Purdue a finales de la década de 1970 para extender el servicio de cron a los 100 usuarios de un sistema VAX de tiempo compartido , se descubrió que sobrecargaba el sistema.

La siguiente versión de cron, con el lanzamiento de Unix System V , se creó para extender sus capacidades a todos los usuarios de un sistema Unix, no solo al superusuario. Si bien esto puede parecer trivial hoy en día, dado que la mayoría de los sistemas Unix y similares cuentan con procesadores potentes y un número reducido de usuarios, en aquel entonces requería un nuevo enfoque en un sistema MIPS con aproximadamente 100 cuentas de usuario.

En el número de agosto de 1977 de Communications of the ACM , WR Franta y Kurt Maly publicaron un artículo titulado "Una estructura de datos eficiente para el conjunto de eventos de simulación", que describía una estructura de datos de cola de eventos para sistemas de simulación discretos basados ​​en eventos que demostraba "un rendimiento superior al de los algoritmos de lista enlazada simple de uso común", un buen comportamiento ante distribuciones de tiempo no uniformes y una complejidad en el peor de los casos baja.${\displaystyle \theta \left({\sqrt {n}}\right)}$, donde "n" es el número de eventos en la cola.

Robert Brown, estudiante de posgrado de Purdue, al revisar este artículo, reconoció el paralelismo entre cron y los simuladores de eventos discretos , y creó una implementación del gestor de listas de eventos Franta-Maly (ELM) para experimentar. Los simuladores de eventos discretos se ejecutan en tiempo virtual , extrayendo eventos de la cola lo más rápido posible y adelantando su noción de "ahora" a la hora programada del siguiente evento. Al ejecutar el simulador de eventos en "tiempo real" en lugar de tiempo virtual, se creó una versión de cron que pasaba la mayor parte del tiempo inactiva, esperando la hora programada para ejecutar la tarea que encabezaba la lista de eventos.

El siguiente año académico, el programa de posgrado de Purdue recibió a nuevos estudiantes, entre ellos Keith Williamson, quien se unió al personal de sistemas del departamento de Ciencias de la Computación. Como "tarea de calentamiento", Brown le pidió que desarrollara el prototipo de cron hasta convertirlo en un servicio de producción, y este cron multiusuario se implementó en Purdue a finales de 1979. Esta versión de cron reemplazó por completo la /etc/cronque se utilizaba en el VAX 11/780 del departamento de ciencias de la computación, que funcionaba a 32 V.

El algoritmo utilizado por este cron es el siguiente:

1. Al iniciar el sistema, busque un archivo con ese nombre .crontaben los directorios personales de todos los titulares de la cuenta.
2. Para cada archivo crontab encontrado, determine la próxima vez en el futuro en que se debe ejecutar cada comando.
3. Coloque esos comandos en la lista de eventos de Franta-Maly con su hora correspondiente y su especificador de hora de "cinco campos".
4. Entrar en el bucle principal:
   1. Examine la entrada de la tarea que se encuentra al principio de la cola y calcule cuánto tiempo después debe ejecutarse.
   2. Duerme durante ese período de tiempo.
   3. Al despertar y tras verificar la hora correcta, ejecute la tarea que se encuentra al principio de la cola (en segundo plano) con los privilegios del usuario que la creó.
   4. Determina el próximo momento en el futuro en el que se ejecutará este comando y vuelve a incluirlo en la lista de eventos en ese momento.

Además, el demonio responde a las señales SIGHUP para volver a escanear los archivos crontab modificados y programa eventos especiales de activación a la hora en punto y a la media hora para buscar archivos crontab modificados. Aquí se omiten muchos detalles sobre las imprecisiones del seguimiento de la hora del ordenador, la programación de alarmas de Unix, los cambios explícitos de hora y la gestión de procesos, que constituyen la mayor parte del código de este cron. Este cron también capturaba la salida de stdout y stderr y enviaba por correo electrónico cualquier resultado al propietario del crontab.

Los recursos consumidos por esta tarea programada (cron) solo aumentan en función de la cantidad de trabajo que se le asigna y no se incrementan inherentemente con el tiempo, con la excepción de la comprobación periódica de cambios.

Williamson completó sus estudios y se graduó de la universidad con una maestría en informática. Se unió a AT&T Bell Labs en Murray Hill, Nueva Jersey, y se llevó consigo este cron. En Bell Labs, él y otros incorporaron el comando Unixat a cron, movieron los archivos crontab de los directorios personales de los usuarios (que no eran específicos del host) a un directorio de cola común específico del host y, por necesidad, agregaron el crontabcomando para permitir que los usuarios copiaran sus crontabs a ese directorio de cola.

Esta versión de cron apareció posteriormente prácticamente sin cambios en Unix System V y en BSD y sus derivados, Solaris de Sun Microsystems , IRIX de Silicon Graphics , HP-UX de Hewlett-Packard y AIX de IBM . Técnicamente, la licencia original de estas implementaciones debería pertenecer a la Fundación de Investigación de Purdue, que financió el trabajo, pero esto ocurrió en una época en la que se prestaba poca atención a estos asuntos.

Con la llegada del Proyecto GNU y Linux , surgieron nuevos cron. El más extendido es Vixie cron, originalmente programado por Paul Vixie en 1987. La versión 3 de Vixie cron se lanzó a finales de 1993. La versión 4.1 pasó a llamarse ISC Cron y se lanzó en enero de 2004. La versión 3, con algunas correcciones de errores menores, se utiliza en la mayoría de las distribuciones de Linux y BSD.

En 2007, Red Hat bifurcó vixie-cron 4.1 al proyecto cronie , agregando características como soporte para PAM y SELinux. ^{[ 13 ]} En 2009, anacron 2.3 se fusionó con cronie. ^{[ 14 ]} Sin embargo, Anacron no es un programa cron independiente; otro trabajo cron debe llamarlo.

El dcron de DragonFly fue creado por su fundador Matt Dillon , y su mantenimiento fue asumido por Jim Pryor en 2010. ^{[ 15 ]}

En 2003, Dale Mellor presentó mcron, ^{[ 16 ]} una variante de cron escrita en Guile que proporciona compatibilidad cruzada con Vixie cron, además de ofrecer mayor flexibilidad, ya que permite el uso de código Scheme arbitrario en cálculos de programación y definiciones de trabajos. Dado que tanto el demonio mcron como los archivos crontab suelen estar escritos en Scheme (aunque mcron también acepta crontabs Vixie tradicionales), el estado acumulativo de la cola de trabajos de un usuario está disponible para su código de trabajo, que puede programarse para ejecutarse si los resultados de otros trabajos cumplen ciertos criterios. Mcron se implementa por defecto bajo el gestor de paquetes Guix , que incluye provisiones ( servicios ) para que el gestor de paquetes emita crontabs mcron de forma monádica, asegurando al mismo tiempo que los paquetes necesarios para la ejecución de trabajos estén instalados y que los crontabs correspondientes hagan referencia a ellos correctamente. ^{[ 17 ]}

Una solución webcron programa tareas de anillo para que se ejecuten periódicamente allí donde no haya implementaciones de cron disponibles en un entorno de alojamiento web .

En 2025, se publicó la Especificación de Patrón Cron Abierta (OCPS) para abordar la fragmentación en la sintaxis de cron en diferentes implementaciones. OCPS 1.0 proporciona una especificación formal del dialecto cron de Vixie, codificando el formato de patrón de cinco campos con reglas explícitas para casos límite previamente ambiguos. ^{[ 18 ]}

La especificación está diseñada como un superconjunto retrocompatible, y se prevé que las futuras versiones añadan gradualmente características como programaciones predefinidas, precisión de segundo nivel y modificadores de calendario avanzados, manteniendo la compatibilidad con versiones anteriores.

Los siguientes son caracteres no estándar y existen solo en algunas implementaciones de cron, como el planificador de tareas Quartz para Java .

L

La letra 'L' significa "último". Cuando se usa en el campo del día de la semana, permite especificar construcciones como "el último viernes" (" 5L ") de un mes determinado. En el campo del día del mes, especifica el último día del mes.

W

El carácter 'W' está permitido para el campo del día del mes. Este carácter se utiliza para especificar el día de la semana (de lunes a viernes) más cercano al día dado. Por ejemplo, si se especifica " 15W " como valor para el campo del día del mes, significa: "el día de la semana más cercano al día 15 del mes". Así, si el día 15 es sábado, el disparador se activa el viernes 14. Si el día 15 es domingo, el disparador se activa el lunes 16. Si el día 15 es martes, entonces se activa el martes 15. Sin embargo, si se especifica "1W" como valor para el día del mes, y el día 1 es sábado, el disparador se activa el lunes 3, ya que no "salta" el límite de los días del mes. El carácter 'W' solo se puede especificar cuando el día del mes es un solo día, no un rango o una lista de días.

Hash ( #)

Se permite el símbolo '#' para el campo del día de la semana, seguido de un número entre uno y cinco. Permite especificar construcciones como "el segundo viernes" de un mes determinado. ^{[ 22 ]} Por ejemplo, al introducir "5#3" en el campo del día de la semana, corresponde al tercer viernes de cada mes.

Signo de interrogación ( ?)

En algunas implementaciones, se usa en lugar de ' * ' para dejar en blanco el día del mes o el día de la semana. Otras implementaciones de cron sustituyen "?" con la hora de inicio del demonio cron, de modo que se actualizaría si cron se iniciara a las 8:25 a. m. y se ejecutaría a esa hora todos los días hasta que se reiniciara de nuevo. ^{[ 23 ]}? ? * * * *25 8 * * * *

Barra inclinada ( /)

En vixie-cron, las barras diagonales se pueden combinar con rangos para especificar valores de paso. ^{[ 8 ]} Por ejemplo, */5 en el campo de minutos indica cada 5 minutos (ver nota a continuación sobre frecuencias). Es una abreviatura de la forma POSIX más detallada 5,10,15,20,25,30,35,40,45,50,55,00 . POSIX no define un uso para las barras diagonales; su justificación (que comenta una extensión de BSD) señala que la definición se basa en el formato System V, pero no excluye la posibilidad de extensiones. ^{[ 6 ]}

Tenga en cuenta que las frecuencias en general no se pueden expresar; solo los valores de paso que dividen uniformemente su rango expresan frecuencias precisas (para minutos y segundos, son /2, /3, /4, /5, /6, /10, /12, /15, /20 y /30 porque 60 es divisible uniformemente por esos números; para horas, son /2, /3, /4, /6, /8 y /12 ); todos los demás "pasos" posibles y todos los demás campos producen períodos "cortos" inconsistentes al final de la unidad de tiempo antes de que se "reinicie" al siguiente minuto, segundo o día; por ejemplo, ingresar */5 para el campo del día a veces se ejecuta después de 1, 2 o 3 días, dependiendo del mes y del año bisiesto; esto se debe a que cron no tiene estado (no recuerda la hora de la última ejecución ni cuenta la diferencia entre ella y ahora, necesaria para un conteo de frecuencia preciso; en cambio, cron es un simple comparador de patrones).

Algunas bibliotecas específicas de lenguaje que ofrecen la capacidad de programación de crontab no requieren rangos "estrictos" 15-59/XX a la izquierda de la barra cuando se usan rangos. ^{[ 24 ]} En estos casos, 15/XX es lo mismo que una programación de vixie-cron de 15-59/10 en la sección de minutos. De manera similar, se puede eliminar el -23 adicional de 0-23/XX , -31 de 1-31/XX y -12 de 1-12/XX para horas, días y meses; respectivamente.

H

La letra 'H' se utiliza en el sistema de integración continua Jenkins para indicar que se sustituye un valor "hash". Así, en lugar de un número fijo como ' 20 * * * *', que significa que la tarea se realiza a los 20 minutos de cada hora, ' H * * * *' indica que la tarea se ejecuta cada hora en un momento indeterminado pero invariable para cada tarea. Esto permite distribuir las tareas a lo largo del tiempo, en lugar de que todas comiencen al mismo tiempo y compitan por los recursos. ^{[ 25 ]}