<Anterior | Contenido | Siguiente>
Es una buena idea elegir tiempos de ejecución extraños, porque los trabajos del sistema a menudo se ejecutan en horas "redondas", como puede ver en la Sección 4.4.4 de la siguiente sección. Por ejemplo, los trabajos a menudo se ejecutan exactamente a la 1 de la mañana (por ejemplo, indexación del sistema para actualizar una base de datos de localización estándar), por lo que ingresar una hora de 0100 puede ralentizar fácilmente su sistema en lugar de encenderlo. Para evitar que los trabajos se ejecuten todos al mismo tiempo, también puede utilizar la lote comando, que pone en cola los procesos y alimenta el trabajo en la cola al sistema de una manera equilibrada, evitando ráfagas excesivas de uso de recursos del sistema. Consulte las páginas de información para obtener más información.
4.4.4. Cron y crontab
El sistema cron está gestionado por el cron demonio. Obtiene información sobre qué programas y cuándo deben ejecutarse desde las entradas crontab del sistema y de los usuarios. Solo el usuario root tiene acceso a las crontabs del sistema, mientras que cada usuario solo debe tener acceso a sus propias crontabs. En algunos sistemas (algunos) los usuarios pueden no tener acceso a la función cron.
Al iniciar el sistema, el demonio cron busca / var / spool / cron / para entradas crontab que llevan el nombre de cuentas en / Etc / passwd, busca /etc/cron.d/ y busca / etc / crontab, luego usa esta información cada minuto para verificar si hay algo que hacer. Ejecuta comandos como el usuario propietario del archivo crontab y envía por correo cualquier salida de comandos al propietario.
En los sistemas que usan cron de Vixie, los trabajos que ocurren cada hora, diariamente, semanalmente y mensualmente se guardan en directorios separados en / Etc para mantener una visión general, a diferencia de la función cron estándar de UNIX, donde todas las tareas se ingresan en un archivo grande.
Ejemplo de un archivo crontab de Vixie:
[root @ blob / etc] # más crontab SHELL = / bin / bash RUTA = / sbin: / bin: / usr / sbin: / usr / bin MAILTO = root
INICIO = /
# ejecutar-partes
# comandos para ejecutar cada hora
01 * * * * partes de ejecución raíz /etc/cron.hourly
# comandos para ejecutar todos los días
02 4 * * * partes de ejecución raíz /etc/cron.daily
# comandos para ejecutar cada semana
22 4 * * 0 comandos root run-parts /etc/cron.weekly para ejecutar cada mes
42 4 1 * * partes de ejecución raíz /etc/cron.monthly
[root @ blob / etc] # más crontab SHELL = / bin / bash RUTA = / sbin: / bin: / usr / sbin: / usr / bin MAILTO = root
INICIO = /
# ejecutar-partes
# comandos para ejecutar cada hora
01 * * * * partes de ejecución raíz /etc/cron.hourly
# comandos para ejecutar todos los días
02 4 * * * partes de ejecución raíz /etc/cron.daily
# comandos para ejecutar cada semana
22 4 * * 0 comandos root run-parts /etc/cron.weekly para ejecutar cada mes
42 4 1 * * partes de ejecución raíz /etc/cron.monthly
Alternative
También podrías usar el crontab -l comando para mostrar crontabs.
Se establecen algunas variables, y luego está la programación real, una línea por trabajo, comenzando con 5 campos de fecha y hora. El primer campo contiene los minutos (de 0 a 59), el segundo define la hora de ejecución (0-23), el tercero es el día del mes (1-31), luego el número del mes (1-12) , el último es el día de la semana (0-7, tanto 0 como 7 son domingo). Un asterisco en estos campos representa el rango total aceptable para el campo. Se permiten listas; para ejecutar un trabajo de lunes a viernes ingrese 1-5 en el último campo, para ejecutar un trabajo los lunes, miércoles y viernes ingrese 1,3,5.
Luego viene el usuario que debe ejecutar los procesos que se enumeran en la última columna. El ejemplo anterior es de una configuración cron de Vixie donde root ejecuta el programa ejecutar-partes en intervalos regulares, con los directorios apropiados como opciones. En estos directorios, los trabajos reales que se ejecutarán a la hora programada se almacenan como scripts de shell, como este pequeño script que se ejecuta a diario para actualizar la base de datos utilizada por el localizar mando:
billy @ ahost cron.daily] $ gato slocate.cron
#! / Bin / sh
renice +19 -p $$> / dev / null 2> & 1
/ usr / bin / updatedb -f "nfs, smbfs, ncpfs, proc, devpts" -e \ "/ tmp, / var / tmp, / usr / tmp, / afs, / net"
billy @ ahost cron.daily] $ gato slocate.cron
#! / Bin / sh
renice +19 -p $$> / dev / null 2> & 1
/ usr / bin / updatedb -f "nfs, smbfs, ncpfs, proc, devpts" -e \ "/ tmp, / var / tmp, / usr / tmp, / afs, / net"
Se supone que los usuarios deben editar sus crontabs de forma segura utilizando el crontab -e mando. Esto evitará que un usuario abra accidentalmente más de una copia de su archivo crontab. El editor predeterminado es vi (consulte el Capítulo 6, pero puede utilizar cualquier editor de texto, como gvim or gedit si se siente más cómodo con un editor de GUI.
Cuando salga, el sistema le dirá que se ha instalado un nuevo crontab.
Esta entrada crontab recuerda porra para ir a su club deportivo todos los jueves por la noche:
billy: ~> crontab -l
# NO EDITE ESTE ARCHIVO - edite el maestro y vuelva a instalarlo.
# (/tmp/crontab.20264 instalado el domingo 20 de julio 22:35:14 2003)
billy: ~> crontab -l
# NO EDITE ESTE ARCHIVO - edite el maestro y vuelva a instalarlo.
# (/tmp/crontab.20264 instalado el domingo 20 de julio 22:35:14 2003)
# (Versión cron - $ Id: chap4.xml, v 1.28 2007/09/19 12:22:26 hasta Exp $)
38 16 * * 3 correos "noche deportiva" billy
# (Versión cron - $ Id: chap4.xml, v 1.28 2007/09/19 12:22:26 hasta Exp $)
38 16 * * 3 correos "noche deportiva" billy
Después de agregar una nueva tarea programada, el sistema le dirá que se instaló un nuevo crontab. No es necesario reiniciar el cron demonio para que los cambios surtan efecto. En el ejemplo, porra agregó una nueva línea que apunta a un script de respaldo:
billy: ~> crontab -e
45 15 * * 3 correos "noche deportiva" billy
4 4 * * 4,7 /home/billy/bin/backup.sh
<- escribir y salir ->
crontab: instalando el nuevo crontab billy: ~>
billy: ~> crontab -e
45 15 * * 3 correos "noche deportiva" billy
4 4 * * 4,7 /home/billy/bin/backup.sh
<- escribir y salir ->
crontab: instalando el nuevo crontab billy: ~>
Se registra en la backup.sh El script se ejecuta todos los jueves y domingos. Consulte la Sección 7.2.5 para obtener una introducción a las secuencias de comandos de shell. Tenga en cuenta que la salida de los comandos, si corresponde, se envía por correo al propietario del archivo crontab. Si no hay ningún servicio de correo configurado, es posible que encuentre la salida de sus comandos en su buzón de correo local,
/ var / spool / mail / , un archivo de texto sin formato.