Los sistemas UNIX están diseñados para estar bastante tiempo activos o en funcionamiento, a diferencia de los PC que en cuanto se finaliza la jornada se apagan, los sistemas UNIX siguen en funcionamiento. Esto es debido fundamentalmente a dos factores:
Si un sistema es estable y se tarda tiempo en pararlo y arrancarlo, ¿Por qué no dejarlo encendido?. Esta cuestión se convierte más en una afirmación cuando el sistema es usado por diferentes turnos de personal.
Si el sistema está funcionando cuando el usuario no está delante del sistema. ¿Por qué no dejar alguna tarea programada, para que cuando llegue al día siguiente tenga menos trabajo que hacer?. Aquí es donde surge el tema de la programación de tareas.
Un usuario puede dejar programado la ejecución de procesos por lotes que no necesiten interacción por parte del usuario, como puede ser la realización de copias de seguridad, generación de informes que consumen un tiempo apreciable, de modo que no tenga que estar mirando al monitor a la espera de que el sistema finalice su ejecución. Además de este modo se descarga el sistema, con lo cual las aplicaciones que se ejecuten irán más rápidas y los demás usuarios se lo agradecerán.
Para programar tareas es conveniente utilizar los periodos de menos carga del sistema, sobre todo si se trata de tareas que consuman bastantes recursos. Es conveniente programarlas a las horas en que menos usuarios haya conectados al sistema, con el fin de que los que estén conectados noten lo menos posible la ejecución de dichas tareas. Para ello, lo ideal es contactar con el administrador del sistema, quien debe conocer la carga del sistema en cada momento, y quien puede permitir o denegar la programación de tareas a un usuario.
Entre las tareas típicas que se ejecutan en modo programado habitualmente, se pueden destacar:
Para la programación de tareas existen, fundamentalmente, dos comandos:
| crontab | crontab archivo |
| at | at hhmm |
La diferencia entre ellos estriba en que mientras con el comando at se programa la ejecución de una tarea para un momento determinado, mediante el cron se pueden programar por días de la semana, hora, mes, etc.
El cron en realidad es un demonio (programa que esta siempre en ejecución) que lee y realiza las tareas programadas por los usuarios en un archivo. Cada usuario tendrá su archivo cron, y existirá una copia del mismo en el directorio /var/spool/cron/crontabs (el directorio puede variar según el sistema), que es de donde en realidad lo lee el demonio. El archivo generalmente tiene el nombre del usuario que lo tiene programado.
Como el usuario que programa las tareas, normalmente no está durante la ejecución de las mismas, lo normal es que reciba los resultados (si ha salido bien o mal) por un correo. Se pueden direccionar los resultados a archivos con el fin de analizar la ejecución de las tareas.
En general pueden existir los siguientes archivos, en los que el administrador autoriza o desautoriza la programación de tareas a los usuarios introduciendo el login en ellos:
La estructura de estos archivos es muy sencilla, tan solo hay que incluir el nombre del usuario en el archivo correspondiente para permitirle o denegarle la posibilidad de ejecución de tareas programadas. Si no existen ni el archivo .allow ni el archivo .deny, los únicos que pueden utilizar el comando son quienes tengan permiso de superusuario (root). Si sólo existe el archivo .deny y éste está vacío, todos los usuarios podrán utilizar el comando. Un usuario podrá programar tareas si aparece el archivo .allow, si este archivo no existe podrá programar tareas siempre y cuando no aparezca en el .deny. Es decir, el archivo .allow tiene preferencia ante el .deny.
Ejemplo:
$ at 4am # (Comando at) lp archivogrande # (Escriba el comando programado para su ejecucion posterior.) .... Ctrl-D # (Termine el comando presionando Ctrl-D.) $ at -l Dar´ una salida del tipo: job 9534782.a at wed Mar 29 4:00:00 2006
Para activar y/o desactivar la ejecución de comandos vía cron se utiliza el comando crontab.
A continuación se muestra un ejemplo de cómo deben ser las líneas incluidas en el archivo en que se programan las tareas a ejecutar vía cron:
mm hh dd MM ss Comando1 ; Comando2 ; Comando3 ...
donde:
mm : Minuto dentro de la hora (0-59)
hh : Hora del día (0-23)
dd : Día del mes (1-31)
MM : Mes del año (1-12)
ss : Día de la semana (0-6, Domingo=0)
Comandos : Secuencia de comandos a ejecutar, deben ir separados con ";", pudiéndose redireccionar tanto la salida estándar como la de errores hacia algún archivo (2>&1).
El uso del comando crontab se puede resumir en:
| crontab -e | edita el archivo cron del usuario |
| crontab -l | muestra las tareas activas en el cron del usuario |
| crontab archivo | activa el contenido del archivo como cron de usuario |
Ejemplo del contenido del archivo cron de un usuario:
0 4 * * * . /etc/TIMEZONE; . /etc/entorno.env; $NMSDIR/sys/logchk 2> /dev/null # Todos los dias a las 04:00
0 0 * 1 * . /etc/TIMEZONE; . /etc/entorno.env; $NMSDIR/ubin/mont_check # Todos los dias 1 de mes a las 00:00
30 5 * * 1 /bin/find /tmp/english -exec touch {} \; > /dev/null 2>&1 # A las 05:30 horas todos los lunes
0 * * * * /bin/su admin -c "sh /usr/lib/acct/ckpacct" # Cada hora en punto todas las horas todos los dias
00 21 * * 0 /sbin/pop_back_root > /dev/null 2>&1 # A las 21:00 todos los domingos
Cuando cualquiera de los campos se marca con un "*" se quiere indicar que esa línea se debe ejecutar para cada valor del campo (cada minuto, cada hora, etc.). En caso de especificar varios valores dentro de un campo se deben separar con comas ",", y se quieren especificar rangos, se deben separar con guiones "-".
Las líneas que comienzan por "#" no se ejecutarán, se entenderá que se trata de un comentario.
Se debe tener cuidado a la hora de programar tareas vía cron con las variables de entorno, pues cron, por defecto toma unos valores estándar, por lo que cualquier modificación debe especificarse en la línea de comandos o en un shell script que sea invocado en la línea de comandos.
En caso de que dos usuarios tengan un cron en el que coincidan, a la misma hora, los mismos programas, se pueden producir resultados inesperados si se actúa sobre los mismos archivos.