ch02 Todo

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 28

Capítulo 2.

Programación de tareas futuras


Programación de un trabajo de usuario diferido
Ejercicio guiado: Programación de un trabajo de usuario diferido
Programación de trabajos de usuario recurrentes
Ejercicio guiado: Programación de trabajos de usuario recurrentes
Programación de trabajos del sistema recurrentes
Ejercicio guiado: Programación de trabajos del sistema recurrentes
Administración de archivos temporales
Ejercicio guiado: Administración de archivos temporales
Cuestionario: Programación de tareas futuras
Resumen

Resumen

Meta Programar tareas para que se ejecuten automáticamente en el futuro


 Configurar un comando que se ejecute una vez en algún momento en el
futuro

 Programar comandos para que se ejecuten en un horario de repetición


usando el archivo crontab de un usuario
Objetivos
 Programar comandos para que se ejecuten en un horario de repetición
usando el archivo crontab del sistema y directorios

 Habilitar y deshabilitar los temporizadores de systemd y configurar un


temporizador que administre archivos temporales

 Programación de un trabajo de usuario diferido (y ejercicio guiado)

 Programación de trabajos de usuario recurrentes (y ejercicio guiado)


Secciones
 Programación de trabajos del sistema recurrentes (y ejercicio guiado)

 Administración de archivos temporales (y ejercicio guiado)

Trabajo de Programación de tareas futuras


laboratorio

Programación de un trabajo de usuario diferido


Objetivos
Después de completar esta sección, debe ser capaz de configurar un comando que se ejecute una vez en
algún momento en el futuro.
Descripción de tareas de usuario diferidas
A veces es posible que necesite ejecutar un comando, o un conjunto de comandos, en un punto fijo en
el futuro. Entre los ejemplos, se incluyen personas que desean programar un correo electrónico para su
jefe, o un administrador de sistemas que está trabajando en una configuración de firewall que pone un
trabajo de “seguridad” en vigencia para restablecer la configuración de firewall en un tiempo de diez
minutos, a menos que desactive el trabajo antes.
Estos comandos programados son a menudo se denominan tareas o trabajos y el termino diferido
indica que estas tareas o trabajos se ejecutarán en el futuro.
Una de las soluciones disponibles para los usuarios de Red Hat Enterprise Linux para la programación
de tareas diferidas es at. El paquete at proporciona el daemon del sistema (atd) junto con un conjunto
de herramientas de línea de comandos para interactuar con el daemon (at, atq y más). En una
instalación Red Hat Enterprise Linux predeterminada, el daemon atd se instala y se habilita
automáticamente.
Los usuarios (incluido root) pueden poner en cola trabajos para el daemon atd con el comando at.
El daemon atd proporciona 26 colas, de la a a la z, con trabajos en colas ordenadas alfabéticamente
que obtienen menos prioridad en el sistema (los valores buenos más altos, se analizan en un capítulo
posterior).
Programación de tareas de usuario diferidas
Use el comando at TIMESPEC para programar un nuevo trabajo. A continuación, el comando at lee los
comandos para ejecutar desde el canal stdin. Cuando ingresa comandos manualmente, puede
terminar su entrada presionando Ctrl+D. Para comandos más complejos que son propensos a errores
tipográficos, a menudo es más fácil usar la redirección de entrada desde un archivo de script, por
ejemplo, at now +5min < myscript, en lugar de escribir todos los comandos manualmente en una
ventana de terminal.
El argumento TIMESPEC con el comando at acepta muchas combinaciones poderosas, lo que permite
a los usuarios describir exactamente cuándo se debe ejecutar un trabajo. Típicamente, comienzan con
una hora, p. ej., 02:00 p. m., 15:59 o incluso teatime (hora del té), seguida de una fecha
opcional o una cantidad de días en el futuro. A continuación, se detalla una lista con algunos ejemplos
de combinaciones que se pueden usar.
 now +5min (ahora + 5 min)

 teatime tomorrow (hora del té mañana) (la hora del té es 16:00)

 noon +4 days (mediodía + 4 días)

 5pm august 3 2021 (3 de agosto de 2021 a las 5:00 p. m.)

Para obtener una lista completa de las especificaciones de tiempo válidas, consulte la definición
timespec como se indica en las referencias.
Inspección y administración de trabajos de usuario diferidos
Para obtener una descripción general de los trabajos pendientes de su usuario, use el comando atq o los
comandos at -l.
[user@host ~]$ atq
28 Mon Feb 2 05:13:00 2015 a user
29 Mon Feb 3 16:00:00 2014 h user
27 Tue Feb 4 12:00:00 2014 a user

En la salida anterior, cada línea representa un trabajo diferente programado para ejecutarse en el futuro.

El número de trabajo único para este trabajo.

La fecha y hora de ejecución del trabajo programado.

Indica que el trabajo está programado con la cola predeterminada a. Se pueden programar
diferentes trabajos con diferentes colas.

El propietario del trabajo (y el usuario con el cual se ejecutará el trabajo).

Importante
Los usuarios no privilegiados solo pueden ver y controlar sus propios trabajos. El
usuario root puede ver y administrar todos los trabajos.

Para inspeccionar los comandos reales que se ejecutarán cuando se ejecute un trabajo, use el comando
at -c JOBNUMBER. Este comando muestra el entorno para el trabajo que se configura para reflejar el
entorno del usuario quien creó el trabajo en el momento en que se creó, seguido de los comandos reales
que se ejecutarán.

Eliminación de trabajos
El comando atrm JOBNUMBER elimina un trabajo programado. Elimine el trabajo programado cuando
ya no es necesario; por ejemplo, cuando una configuración de firewall remota dio un resultado
satisfactorio, y no es necesario que se restablezca.

Referencias
Páginas del manual: at(1) y atd(8)
/usr/share/doc/at/timespec
Ejercicio guiado: Programación de un trabajo de usuario
diferido
En este ejercicio, usara el comando at para programar varios comandos para ejecutar en momentos
específicos en el futuro.
Resultados
Usted deberá ser capaz de realizar lo siguiente:
 Programar un trabajo para que se ejecute en un momento específico en el futuro
 Inspeccionar los comandos que ejecuta un trabajo programado
 Eliminar los trabajos programados
Inicie sesión en workstation como student con la contraseña student.

En workstation, ejecute lab scheduling-at start para comenzar el ejercicio. Este script asegura
que el entorno esté limpio y configurado correctamente.
[student@workstation ~]$ lab scheduling-at start

1. Desde workstation, abra una sesión de SSH en servera como student.


[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$

2. Programe un trabajo para ejecutar en tres minutos a partir de ahora usando el comando at. El
trabajo debe guardar la salida del comando date en /home/student/myjob.txt.

1. Use el comando echo para pasar la cadena fecha >>/home/student/myjob.txt


como entrada al comando at para que el trabajo se ejecute en tres minutos a partir de ahora.
[student@servera ~]$ echo "date >> /home/student/myjob.txt" | at now +3min
warning: commands will be executed using /bin/sh
job 1 at Thu Mar 21 12:30:00 2019

2. Use el comando atq para enumerar los trabajos programados.


[student@servera ~]$ atq
1 Thu Mar 21 12:30:00 2019 a student

3. Use el comando watch atq para monitorear la cola de los trabajos diferidos en tiempo real.
El trabajo se elimina de la cola después de su ejecución.
[student@servera ~]$ watch atq
Every 2.0s: atq servera.lab.example.com: Thu Mar 21 12:30:00 2019

1 Thu Mar 21 12:30:00 2019 a student


De manera predeterminada, el comando watch precedente actualiza la salida de atq cada
dos segundos. Después de que el trabajo aplazado se elimine de la cola, presione Ctrl+c
para salir de watch y volver al prompt de shell.
4. Use el comando cat para verificar que el contenido de /home/student/myjob.txt
coincida con la salida del comando date.
[student@servera ~]$ cat myjob.txt
Thu Mar 21 12:30:00 IST 2019

La salida anterior coincide con la salida del comando date, confirmando que el trabajo
programado se ejecutó con éxito.
3. Use el comando at para programar interactivamente un trabajo con la cola g que se ejecuta en
teatime (16:00). El trabajo debe ejecutar un comando que imprima el mensaje It's
teatime (Es la hora del té) en /home/student/tea.txt. Los nuevos mensajes deben
adjuntarse al archivo /home/student/tea.txt.
[student@servera ~]$ at -q g teatime
warning: commands will be executed using /bin/sh
at> echo "It's teatime" >> /home/student/tea.txt
at> Ctrl+d
job 2 at Thu Mar 21 16:00:00 2019

4. Use el comando at para programar interactivamente otro trabajo con la cola b que se ejecuta en
16:05. El trabajo debe ejecutar un comando que imprima el mensaje The cookies are
good (Las galletas están bien) en /home/student/cookies.txt. Los nuevos mensajes
deben adjuntarse al archivo /home/student/cookies.txt.
[student@servera ~]$ at -q b 16:05
warning: commands will be executed using /bin/sh
at> echo "The cookies are good" >> /home/student/cookies.txt
at> Ctrl+d
job 3 at Thu Mar 21 16:05:00 2019

5. Inspeccione los comandos en los trabajos pendientes.


1. Use el comando atq para ver los números de trabajo de los trabajos pendientes.
[student@servera ~]$ atq
2 Thu Mar 21 16:00:00 2019 g student
3 Thu Mar 21 16:05:00 2019 b student

Tenga en cuenta los números de trabajo de la salida anterior. Estos números de trabajo
pueden variar en su sistema.
2. Use el comando at para ver los números de trabajo del trabajo pendiente número 2.
[student@servera ~]$ at -c 2
...output omitted...
echo "It's teatime" >> /home/student/tea.txt
marcinDELIMITER28d54caa
Observe que el trabajo programado anterior ejecuta un comando echo que agrega el mensaje
It's teatime (Es la hora del té) a /home/student/tea.txt.

3. Use el comando at para ver los comandos del trabajo pendiente número 3.
[student@servera ~]$ at -c 3
...output omitted...
echo "The cookies are good" >> /home/student/cookies.txt
marcinDELIMITER1d2b47e9

Observe que el trabajo programado anterior ejecuta un comando echo que agrega el mensaje
The cookies are good (Las galletas están bien) a
/home/student/cookies.txt.

6. Use el comando atq para ver el número de trabajo de un trabajo que se ejecuta en
teatime(16:00) y quítelo usando el comando atrm.
[student@servera ~]$ atq
2 Thu Mar 21 16:00:00 2019 g student
3 Thu Mar 21 16:05:00 2019 b student
[student@servera ~]$ atrm 2

7. Verifique que el trabajo programado para ejecutarse en teatime (16:00) ya no exista.

1. Use el comando atq para ver la lista de trabajos pendientes y confirmar que el trabajo
programado para ejecutarse en teatime (16:00) ya no existe.
[student@servera ~]$ atq
3 Thu Mar 21 16:05:00 2019 b student

2. Cierre sesión en servera.


[student@servera ~]$ exit
logout
Connection to servera closed.
[student@workstation ~]$

Finalizar
En workstation, ejecute lab scheduling-at finish para terminar este ejercicio. Este script elimina
los archivos creados durante el ejercicio para garantizar que el entorno quede limpio.
[student@workstation ~]$ lab scheduling-at finish

Esto concluye el ejercicio guiado.


Programación de trabajos de usuario recurrentes
Objetivos
Después de finalizar esta sesión, debe programar comandos para que se ejecuten en un horario de
repetición usando el archivo crontab de un usuario.

Descripción de trabajos de usuario recurrentes


Los trabajos programados para ejecutarse repetidamente se llaman trabajos recurrentes. Los sistemas
Red Hat Enterprise Linux se envían con el daemon crond, proporcionado por el paquete cronie,
habilitado e iniciado de forma predeterminada específicamente para trabajos recurrentes. El daemon
crond lee múltiples archivos de configuración: uno por usuario (editado con el comando crontab) y
un conjunto de archivos en todo el sistema. Estos archivos de configuración les dan a los usuarios y
administradores el control detallado cuando sus trabajos recurrentes deben ser ejecutados.
Si un comando programado no produce ninguna salida o un error de que no está redirigido, el daemon
crond intenta enviar por correo electrónico esa salida al usuario que es propietario de ese trabajo (a
menos que se haya anulado) usando el servidor de correo configurado en el sistema. Según el entorno,
es posible que sea necesaria una configuración adicional. La salida o el error del comando programado
se puede redirigir a diferentes archivos.

Programación de trabajos de usuario recurrentes


Los usuarios normales pueden usar el comando crontab para administrar sus trabajos. Este comando se
puede denominar de cuatro maneras diferentes:
Tabla 2.1. Ejemplos de crontab

Comando Uso previsto


Detallar los trabajos para el usuario actual.
crontab -l
Eliminar todos los trabajos del usuario actual.
crontab -r
Editar trabajos para el usuario actual.
crontab -e
Eliminar todos los trabajos y reemplazar con los trabajos leídos de nombre de
crontab
archivo. Si no se especifica ningún archivo, se usa stdin.
filename
Nota
El superusuario puede usar la opción -u con el comando crontab para administrar
trabajos para otro usuario. No debe usar el comando crontab para administrar trabajos
del sistema; en cambio, use los métodos descritos en la siguiente sección.

Descripción del formato de trabajo del usuario


El comando crontab -e invoca a Vim de manera predeterminada, a menos que la variable de entorno
EDITOR se haya establecido en otro ajuste. Ingrese un trabajo por línea. Otras entradas válidas
incluyen: líneas vacías, generalmente para facilitar la lectura; comentarios, identificados por líneas que
comienzan con el signo de número (#); y variables de entorno usando el formato NAME=value, que
afecta a todas las líneas debajo de la línea donde se declaran. Los ajustes de variables comunes
incluyen la variable SHELL, que declara qué shell usar para interpretar las líneas restantes del archivo
crontab; y la variable MAILTO, que determina quién debe recibir la salida enviada por correo
electrónico.

Importante
Enviar un correo electrónico puede requerir la configuración adicional del servidor de
correo local o la retransmisión SMTP en un sistema.
Los campos en el archivo crontab aparecen en el siguiente orden:

 Minutes (Minutos)
 Hours (Horas)
 Day of month (Día del mes)
 Month (Mes)
 Day of week (Día de la semana)
 Command (Comando)

Importante
Cuando los campos Day of month (Día del mes) y Day of week (Día de la
semana) son ambos distintos de *, el comando se ejecuta cuando se cumple cualquiera
de estos dos campos. Por ejemplo, para ejecutar un comando el 15 de cada mes, y todos
los viernes a las 12:15, use el siguiente formato de trabajo:
15 12 15 * Fri command

Los primeros cinco campos usan las mismas reglas de sintaxis:


 * para “No importa”/siempre.
 Un número para especificar una cantidad de minutos u horas, una fecha o un día de la semana.
Para los días de semana, 0 equivale a domingo, 1 equivale a lunes, 2 equivale a martes, etc. 7
también equivale a domingo.
 x-y para un rango, x hasta y inclusive.

 x,y para listas. Las listas también pueden incluir rangos, por ejemplo, 5,10-13,17 en la
columna Minutes (Minutos) para indicar que un trabajo debe ejecutarse a los 5 minutos, a los
10 minutos, a los 11 minutos, a los 12 minutos, a los 13 minutos y a los 17 minutos de la hora.
 */x para indicar un intervalo de x, por ejemplo, */7 en la columna Minutes (Minutos)
ejecuta un trabajo exactamente cada siete minutos.
Asimismo, se pueden usar abreviaturas en inglés de tres letras para los meses y los días de la semana,
por ejemplo, Jan (enero), Feb (febrero) y Mon (lunes), Tue (martes).
El último campo contiene el comando que se ejecutará usando la shell predeterminada. La variable del
entorno SHELL se puede usar para cambiar la shell para el comando programado. Si el comando
contiene un símbolo de porcentaje no codificado (%), ese símbolo de porcentaje se tratará como el
carácter de una línea nueva, y todo lo que esté después del símbolo de porcentaje se enviará al
comando en stdin.

Ejemplos de trabajos de usuario recurrentes


En esta sección, se describen algunos ejemplos de trabajos recurrentes.
 El siguiente trabajo ejecuta el comando /usr/local/bin/yearly_backup exactamente a las
9:00 a. m. el 2 de febrero, todos los años.
0 9 2 2 * /usr/local/bin/yearly_backup

 El siguiente trabajo envía un correo electrónico que contiene la palabra Chime al propietario de
este trabajo, cada cinco minutos entre las 9:00 a. m. y las 5:00 p. m., todos los viernes de julio.
*/5 9-16 * Jul 5 echo "Chime"

El rango de horas precedente 9-16 significa que el temporizador de trabajo comienza a la hora
novena (09:00) y continúa hasta el final de la decimosexta hora (16:59). El trabajo comienza a
ejecutarse a las 09:00 con la última ejecución a las 16:55 porque a cinco minutos de las
16:55 es 17:00 que está más allá del alcance de las horas dadas.

 El siguiente trabajo ejecuta el comando /usr/local/bin/daily_report todas las semanas dos


minutos antes de la medianoche.
58 23 * * 1-5 /usr/local/bin/daily_report

 El siguiente trabajo ejecuta el comando mutt para enviar el mensaje de correo Checking in
al destinatario boss@example.com en cada día de trabajo (lunes a viernes), a las 9:00 a. m.
0 9 * * 1-5 mutt -s "Checking in" boss@example.com % Hi there boss, just
checking in.

Referencias
Páginas del manual: crond(8), crontab(1), crontab(5)
Ejercicio guiado: Programación de trabajos de usuario
recurrentes
En este ejercicio, programará comandos para ejecutar en un programa de repetición como un usuario no
privilegiado, usando el comando crontab.
Resultados
Usted deberá ser capaz de realizar lo siguiente:
 Programar trabajos recurrentes para ejecutar como usuario no privilegiado
 Inspeccionar los comandos que ejecuta un trabajo recurrente programado
 Eliminar trabajos recurrentes programados
Inicie sesión en workstation como student con la contraseña student.

En workstation, ejecute lab scheduling-cron start para comenzar el ejercicio. Este script asegura
que el entorno esté limpio y configurado correctamente.
[student@workstation ~]$ lab scheduling-cron start

1. Desde workstation, abra una sesión de SSH en servera como student.


[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$

2. Programar un trabajo recurrente como student que anexa la fecha y hora actual a
/home/student/my_first_cron_job.txt cada dos minutos entre 8:00 a. m. y
9:00 p. m. El trabajo solo debe ejecutarse de lunes a viernes, no los sábados ni los domingos.

Importante
Si está trabajando en este laboratorio fuera del día y la hora mencionados en la
instrucción anterior, debe ajustar la hora o la fecha del sistema en consecuencia
para que el trabajo se ejecute mientras está trabajando.
2.1.Use el comando crontab -e para abrir el crontab usando el editor de texto predeterminado.
[student@servera ~]$ crontab -e

2.2.Inserte la siguiente línea.


*/2 08-20 * * Mon-Fri /usr/bin/date >> /home/student/my_first_cron_job.txt

2.3.Mientras esté en el editor de texto, presione Esc y escriba :wq para guardar los cambios y
salir del editor. Cuando el editor sale, debe ver la siguiente salida:
...output omitted...
crontab: installing new crontab
[student@servera ~]$

En la salida anterior, se confirma que el trabajo se programó correctamente.


3. Use el comando crontab -l para enumerar los trabajos recurrentes programados. Inspeccione el
comando que programó para que se ejecute como un trabajo recurrente en el paso anterior.
[student@servera ~]$ crontab -l
*/2 08-20 * * Mon-Fri /usr/bin/date >> /home/student/my_first_cron_job.txt

Observe que el trabajo programado anterior ejecuta el comando /usr/bin/date y agrega su salida
a /home/student/my_first_cron_job.txt.

4. Use el comando while para que su prompt de shell duerma hasta que se cree el archivo
/home/student/my_first_cron_job.txt como resultado de la ejecución exitosa del
trabajo recurrente que programó. Espere a que regrese su prompt de shell.
[student@servera ~]$ while ! test -f my_first_cron_job.txt; do sleep 1s; done

El comando anterior while usa ! test -f para continuar ejecutando un bucle de comandos sleep
1s hasta que se crea el archivo my_first_cron_job.txt en el directorio
/home/student.

5. Use el comando cat para verificar que el contenido de


/home/student/my_first_cron_job.txt coincida con la salida del comando date.
[student@servera ~]$ cat my_first_cron_job.txt
Fri Mar 22 13:56:01 IST 2019

La salida anterior puede variar en su sistema.


6. Elimine todos los trabajos recurrentes programados para ejecutarse como student.

6.1.Use el comando crontab -r para eliminar todos los trabajos recurrentes programados para
student.
[student@servera ~]$ crontab -r

6.2.Use el comando crontab -l para verificar que no existen trabajos recurrentes para
student.
[student@servera ~]$ crontab -l
no crontab for student

6.3.Cierre sesión en servera.


[student@servera ~]$ exit
logout
Connection to servera closed.
[student@workstation ~]$
Finalizar
En workstation, ejecute lab scheduling-cron finish para terminar este ejercicio. Este script
elimina los archivos creados durante el ejercicio para garantizar que el entorno quede limpio.
[student@workstation ~]$ lab scheduling-cron finish

Esto concluye el ejercicio guiado.


Programación de trabajos del sistema recurrentes
Objetivos
Después de finalizar esta sesión, debe programar comandos para que se ejecuten en una programación
de repetición usando el archivo crontab y directorios del sistema.

Descripción de trabajos del sistema recurrentes


Los administradores de sistemas a menudo necesitan ejecutar trabajos recurrentes. La mejor práctica es
ejecutar estos trabajos desde cuentas del sistema en lugar de desde cuentas de usuario. Es decir, no
programe para ejecutar estos trabajos usando el comando crontab, pero en su lugar usa archivos
crontab en todo el sistema. Las entradas de trabajo en los archivos crontab en todo el sistema son
similares a los de las entradas de crontab de los usuarios, excepto que los archivos crontab en todo el
sistema tienen un campo adicional antes del campo de comando; el usuario bajo cuya autoridad debe
ejecutarse el comando.
El archivo /etc/crontab tiene un diagrama de sintaxis útil en los comentarios incluidos.
# For details see man 4 crontabs

# Example of job definition:


# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue ...
# | | | | |
# * * * * * user-name command to be executed

Los trabajos recurrentes del sistema se definen en dos ubicaciones: el archivo /etc/crontab y los
archivos dentro del directorio /etc/cron.d/. Siempre debe crear sus archivos crontab
personalizados bajo el directorio /etc/cron.d para programar trabajos recurrentes del sistema.
Coloque el archivo crontab personalizado en /etc/cron.d para evitar que se sobrescriba si se
produce alguna actualización del paquete al proveedor de /etc/crontab, que puede sobrescribir los
contenidos existentes en /etc/crontab. Los paquetes que requieren trabajos recurrentes del sistema
colocan sus archivos crontab en /etc/cron.d/ que contiene las entradas de trabajo. Los
administradores también usan esta ubicación para agrupar trabajos relacionados en un solo archivo.
El sistema crontab también incluye repositorios para scripts que necesitan ejecutarse cada hora, día,
semana y mes. Estos repositorios son directorios llamados /etc/cron.hourly/,
/etc/cron.daily/, /etc/cron.weekly/ y /etc/cron.monthly/. Una vez más, estos
directorios contienen scripts de shell ejecutables, no archivos crontab.
Importante
Recuerde hacer que todos los scripts que coloque en estos directorios sean ejecutables.
Si un script no es ejecutable, no se ejecutará. Para hacer un script ejecutable, use el
comando chmod +x script_name.

Un comando llamado run-parts desde el archivo /etc/cron.d/0hourly ejecuta los scripts


/etc/cron.hourly/*. El comando run-parts también ejecuta los trabajos diarios, semanales y
mensuales también, pero desde un archivo de configuración diferente denominado
/etc/anacrontab.

Nota
En el pasado, un servicio separado llamado anacron se usaba para manejar el archivo
/etc/anacrontab, pero en Red Hat Enterprise Linux 7 y posterior, el servicio
crond regular analiza este archivo.

El propósito de /etc/anacrontab es garantizar que los trabajos importantes siempre se ejecuten, y


que no se omitan accidentalmente porque el sistema se apagó o quedó inactivo cuando el trabajo
debería haberse ejecutado. Por ejemplo, si un trabajo del sistema que se ejecuta diariamente no se
ejecutó la última vez que venció debido a que el sistema se estaba reiniciando, el trabajo se ejecuta
cuando el sistema está listo. Sin embargo, puede haber una demora de varios minutos para comenzar el
trabajo según el valor del parámetro Delay in minutes especificado para el trabajo en
/etc/anacrontab.

Hay diferentes archivos en /var/spool/anacron/ para cada uno de los trabajos diarios,
semanales y mensuales para determinar si un trabajo en particular se ha ejecutado. Cuando crond
comienza un trabajo desde /etc/anacrontab, actualiza los sellos de hora de esos archivos. El
mismo sello de hora se usa para determinar cuándo se ejecutó un trabajo por última vez. La sintaxis de
/etc/anacrontab es diferente a la de los archivos de configuración de crontab regulares.
Contiene exactamente cuatro campos por línea, como se detalla a continuación.
 Period in days (Período en días)

El intervalo en días para el trabajo que se ejecuta en una programación de repetición. Este
campo acepta un entero o una macro como su valor. Por ejemplo, la macro @daily es
equivalente al entero 1, lo que significa que el trabajo se ejecuta diariamente. De manera
similar, la macro @weekly es equivalente al entero 7, lo que significa que el trabajo se ejecuta
diariamente.
 Delay in minutes (Demora en minutos)

Cantidad de tiempo que el daemon crond debe esperar antes de iniciar este trabajo.

 Job identifier (Identificador del trabajo)


El nombre único con se identifica en los mensajes de registro.
 Comando (Comando)

El comando que se ejecutará.


El archivo /etc/anacrontab también contiene declaraciones variables del entorno que usan la
sintaxis NAME=value. De especial interés es la variable START_HOURS_RANGE, que especifica el
intervalo de tiempo para que se ejecuten los trabajos. Los trabajos no se inician fuera de este rango. Si
en un día en particular, un trabajo no se ejecuta dentro de este intervalo de tiempo, el trabajo tiene que
esperar hasta el día siguiente para su ejecución.

Presentación del temporizador systemd


Con el advenimiento de systemd en Red Hat Enterprise Linux 7, una nueva función de programación
ya está disponible: unidades de temporizador systemd. Una unidad de temporizador systemd
activa otra unidad de un tipo diferente (como un servicio) cuyo nombre de unidad coincide con el
nombre de la unidad del temporizador. La unidad del temporizador permite la activación basada en el
temporizador de otras unidades. Para facilitar la depuración, systemd registra los eventos del
temporizador en los diarios (journals) del sistema.
Unidad de temporizador de muestra
El paquete sysstat proporciona una unidad de temporizador systemd llamada sysstat-
collect.timer para recopilar estadísticas del sistema cada 10 minutos. En la siguiente salida, se
muestran las líneas de configuración de /usr/lib/systemd/system/sysstat-
collect.timer.
...output omitted...
[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10

[Install]
WantedBy=sysstat.service

El parámetro OnCalendar=*:00/10 significa que esta unidad de temporizador activa la unidad


correspondiente (sysstat-collect.service) cada 10 minutos, Sin embargo, puede especificar
intervalos de tiempo más complejos. Por ejemplo, un valor de 2019-03-* 12:35,37,39:16
frente al parámetro OnCalendar hace que la unidad del temporizador active la unidad de servicio
correspondiente en 12:35:16, 12:37:16 y 12:39:16 todos los días durante todo el mes de marzo
de 2019. También puede especificar temporizadores relativos usando parámetros tal como
OnUnitActiveSec. Por ejemplo, la opción OnUnitActiveSec=15min hace que la unidad del
temporizador desencadena la unidad correspondiente 15 minutos después de la última vez que la
unidad del temporizador activó su unidad correspondiente.
Importante
No modifique ningún archivo de configuración de la unidad bajo el directorio
/usr/lib/systemd/system porque cualquier actualización al paquete del
proveedor del archivo de configuración puede anular los cambios de configuración que
realizó en ese archivo. Por lo tanto, haga una copia del archivo de configuración de la
unidad que desea cambiar bajo el directorio /etc/systemd/system y, luego,
modifique la copia para que los cambios de configuración que realice con respecto a una
unidad no se anulen con ninguna actualización del paquete del proveedor. Si existen dos
archivos con el mismo nombre bajo los directorios /usr/lib/systemd/system y
/etc/systemd/system, systemd analiza el archivo bajo el directorio
/etc/systemd/system.

Después de cambiar el archivo de configuración de la unidad del temporizador, use el comando


systemctl daemon-reload para asegurar que systemd tenga conocimiento de los cambios. Este
comando recarga la configuración del administrador de systemd.
[root@host ~]# systemctl daemon-reload

Después de recargar la configuración del administrador systemd, use el siguiente comando systemctl
para activar la unidad del temporizador.
[root@host ~]# systemctl enable --now <unitname>.timer

Referencias
Páginas del manual crontab(5),anacron(8),anacrontab(5), systemd.time(7),
systemd.timer(5) y crond(8)
Ejercicio guiado: Programación de trabajos del sistema
recurrentes
En este ejercicio, programará comandos para que se ejecuten en varios horarios agregando archivos de
configuración a los directorios crontab del sistema.
Resultados
Usted deberá ser capaz de realizar lo siguiente:
 Programar un trabajo del sistema recurrente para contar el número de usuarios activos
 Actualizar la unidad de temporizador systemd que recopila los datos de actividad del sistema.

Inicie sesión en workstation como student con la contraseña student.

En workstation, ejecute lab scheduling-system start para comenzar el ejercicio. Este script
asegura que el entorno esté limpio y configurado correctamente.
[student@workstation ~]$ lab scheduling-system start

1. Desde workstation, abra una sesión de SSH en servera como student.


[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$

2. Use el comando sudo -i para cambiar a la cuenta del usuario root.


[student@servera ~]$ sudo -i
[sudo] password for student: student
[root@servera ~]#

3. Programe un trabajo del sistema recurrente que genere un mensaje de registro que indique la
cantidad de usuarios activos actualmente en el sistema. El trabajo debe ejecutarse diariamente.
Puede usar el comando w -h | wc -l para recuperar el número de usuarios actualmente activos en
el sistema. También, use el comando logger para generar el mensaje de registro.
3.1.Cree un archivo de script llamado /etc/cron.daily/usercount con el siguiente
contenido. Puedes usar el comando vi /etc/cron.daily/usercount para crear el archivo de
script.
#!/bin/bash
USERCOUNT=$(w -h | wc -l)
logger "There are currently ${USERCOUNT} active users"

3.2.Use el comando chmod para habilitar el permiso ejecutable (x) en


/etc/cron.daily/usercount.
[root@servera ~]# chmod +x /etc/cron.daily/usercount
4. El paquete sysstat proporciona las unidades systemd denominadas sysstat-
collect.timer y sysstat-collect.service. La unidad del temporizador
desencadena la unidad de servicio cada 10 minutos para recopilar datos de actividad del sistema
usando el script de shell llamado /usr/lib64/sa/sa1. Asegúrese de que el paquete sysstat
se instale y cambie el archivo de configuración de la unidad del temporizador para que recopile
los datos de actividad del sistema cada dos minutos.
4.1.Use el comando yum para instalar el paquete sysstat.
[root@servera ~]# yum install sysstat
...output omitted...
Is this ok [y/N]: y
...output omitted...
Installed:
sysstat-11.7.3-2.el8.x86_64 lm_sensors-libs-3.4.0-
17.20180522git70f7e08.el8.x86_64

Complete!

4.2.Copie /usr/lib/systemd/system/sysstat-collect.timer en
/etc/systemd/system/sysstat-collect.timer.
[root@servera ~]# cp /usr/lib/systemd/system/sysstat-collect.timer \
/etc/systemd/system/sysstat-collect.timer

Importante
No debe editar archivos bajo el directorio /usr/lib/systemd. Con
systemd, puede copiar el archivo de la unidad al directorio
/etc/systemd/system y editar esa copia. El proceso de systemd
analiza su copia personalizada en lugar del archivo bajo el directorio
/usr/lib/systemd.

4.3.Edite /etc/systemd/system/sysstat-collect.timer para que la unidad del


temporizador funcione cada dos minutos. Además, reemplace todas las apariciones de la
cadena 10 minutes con 2 minutes en todo el archivo de configuración de la unidad,
incluidos los de las líneas comentadas. Puede usar el comando vi
/etc/systemd/system/sysstat-collect.timer para editar el archivo de configuración.
...
# Activates activity collector every 2 minutes

[Unit]
Description=Run system activity accounting tool every 2 minutes

[Timer]
OnCalendar=*:00/02

[Install]
WantedBy=sysstat.service
Los cambios anteriores causan que la unidad sysstat-collect. timer desencadene
la unidad de sysstat-collect.service cada dos minutos, que ejecuta
/usr/lib64/sa/sa1 1 1. La ejecución de /usr/lib64/sa/sa1 1 1 recopila los datos de actividad
del sistema en un archivo binario bajo el directorio /var/log/sa.

4.4.Use el comando systemctl daemon-reload para asegurarse de que systemd conozca los
cambios.
[root@servera ~]# systemctl daemon-reload

4.5.Use el comando systemctl para activar la unidad del temporizador sysstat-


collect.timer.
[root@servera ~]# systemctl enable --now sysstat-collect.timer

4.6.Use el comando while para esperar hasta que el archivo binario se cree bajo el directorio
/var/log/sa. Espere a que regrese su prompt de shell.
[root@servera ~]# while [ $(ls /var/log/sa | wc -l) -eq 0 ]; \
do sleep 1s; done

En el comando while de arriba, el ls /var/log/sa | wc -l devuelve un 0 si el archivo no existe


y un 1 si existe. El while determina si es igual a 0 y si es así, ingresa al bucle, que se
detiene por un segundo. Cuando el archivo existe, el bucle while se cierra.
4.7.Use el comando ls -l para verificar que el archivo binario bajo el directorio /var/log/sa
se modificó en los últimos dos minutos.
[root@servera ~]# ls -l /var/log/sa
total 8
-rw-r--r--. 1 root root 5156 Mar 25 12:34 sa25
[root@servera ~]# date
Mon Mar 25 12:35:32 +07 2019

La salida del comando anterior puede variar en su sistema.


4.8.Salga de la shell del usuario root y cierre sesión en servera.
[root@servera ~]# exit
logout
[student@servera ~]$ exit
logout
Connection to servera closed.
[student@workstation ~]$

Finalizar
En workstation, ejecute lab scheduling-system finish para terminar este ejercicio. Este script
elimina los archivos creados durante el ejercicio para garantizar que el entorno quede limpio.
[student@workstation ~]$ lab scheduling-system finish
Administración de archivos temporales
Objetivos
Después de finalizar esta sesión, debe ser capaz de habilitar y deshabilitar los temporizadores de
systemd y configurar un temporizador que administre archivos temporales.

Administración de archivos temporales


Un sistema moderno requiere una gran cantidad de archivos y directorios temporales. Algunas
aplicaciones (y usuarios) usan el directorio /tmp para almacenar datos temporales, mientras que otros
usan una ubicación específica de la tarea como daemon y directorios volátiles específicos del usuario
bajo /run. En este contexto, volátil significa que el sistema de archivos que almacena estos archivos
solo existe en la memoria. Cuando el sistema vuelva a arrancar o pierda potencia, todo el contenido del
almacenamiento volátil desaparecerá.
Para mantener un sistema ejecutándose de forma ordenada, es necesario que estos directorios y
archivos se creen cuando no existen, dado que los daemons y scripts podrían contar con que estos estén
allí, y que los archivos antiguos se purguen de modo que no puedan llenar espacio en el disco ni
proporcionar información errónea.
Red Hat Enterprise Linux 7 y posteriores incluyen una nueva herramienta llamada systemd-tmpfiles,
que proporciona un método estructurado y configurable para administrar directorios y archivos
temporales.
Cuando systemd inicia un sistema, una de las primeras unidades de servicio iniciadas es systemd-
tmpfiles-setup. Este servicio ejecuta el comando systemd-tmpfiles --create --remove. Este
comando lee los archivos de configuración de /usr/lib/tmpfiles.d/*.conf,
/run/tmpfiles.d/*.conf y /etc/tmpfiles.d/*.conf. Todos los archivos y directorios
marcados para la eliminación en esos archivos de configuración se eliminarán, y todos los archivos y
directorios marcados para la creación (o arreglos de permisos) se crearán con los permisos correctos si
es necesario.
Limpieza de archivos temporales con un temporizador de systemd
Para asegurar que los sistemas de larga duración no llenan sus discos con datos obsoletos, una unidad
de temporizador systemd llamada systemd-tmpfiles-clean.timer desencadena
systemd-tmpfiles-clean.service en un intervalo regular, que ejecuta el comando systemd-
tmpfiles --clean.
Los archivos de configuración de la unidad del temporizador systemd tienen una sección [Timer]
que indica con qué frecuencia debe iniciarse el servicio con el mismo nombre.
Use el siguiente comando systemctl para ver los contenidos del archivo de configuración de la unidad
systemd-tmpfiles-clean.timer.
[user@host ~]$ systemctl cat systemd-tmpfiles-clean.timer
# /usr/lib/systemd/system/systemd-tmpfiles-clean.timer
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published
# by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.

[Unit]
Description=Daily Cleanup of Temporary Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d

En la configuración anterior, el parámetro OnBootSec=15min indica que la unidad de servicio


llamada systemd-tmpfiles-clean.service se desencadena 15 minutos después de que el
sistema se haya iniciado. El parámetro OnUnitActiveSec=1d indica que cualquier otro
desencadenador para la unidad de servicio systemd-tmpfiles-clean.service ocurre 24
horas después de que la unidad de servicio se activó por última vez.
En función de sus necesidades, puede cambiar los parámetros en el archivo de configuración de la
unidad del temporizador systemd-tmpfiles-clean.timer. Por ejemplo, el valor 30 min para
el parámetro OnUnitActiveSec desencadena la unidad de servicio systemd-tmpfiles-
clean.service 30 minutos después de la última activación de la unidad de servicio. Como
resultado, systemd-tmpfiles-clean.service se activa cada 30 minutos después de que los
cambios surtan efecto.
Después de cambiar el archivo de configuración de la unidad del temporizador, use el comando
systemctl daemon-reload para asegurar que systemd tenga conocimiento de los cambios. Este
comando recarga la configuración del administrador systemd.
[root@host ~]# systemctl daemon-reload

Después de recargar la configuración del administrador systemd, use el siguiente comando systemctl
para activar la unidad systemd-tmpfiles-clean.timer.
[root@host ~]# systemctl enable --now systemd-tmpfiles-clean.timer

Limpieza de archivos temporales manualmente


El comando systemd-tmpfiles --clean analiza los mismos archivos de configuración que el comando
systemd-tmpfiles --create, pero en lugar de crear archivos y directorios, purgará todos los archivos a
los que no se haya accedido, y que no hayan sido modificados ni cambiados en una fecha anterior a la
antigüedad máxima definida en el archivo de configuración.
El formato de los archivos de configuración para systemd-tmpfiles se detalla en la página del manual
tmpfiles.d(5). La sintaxis básica consta de siete columnas: Tipo, Ruta, Modo, UID, GID, Edad y
Argumento. Tipo se refiere a la acción que debe realizar systemd-tmpfiles; por ejemplo, d ara crear un
directorio si no existe aún, o Z para restaurar recursivamente contextos de SELinux y propiedad y
permisos de archivos.
A continuación, se dan algunos ejemplos con explicaciones:
d /run/systemd/seats 0755 root root -

Cuando cree archivos y directorios, cree el directorio /run/systemd/seats si aún no existe,


propiedad del usuario root y el grupo root, con permisos establecidos para rwxr-xr-x. Este
directorio no se purgará automáticamente.
D /home/student 0700 student student 1d

Cree el directorio /home/student si aún no existe. Si existe, vacíe todos los contenidos. Cuando
systemd-tmpfiles --clean se ejecute, elimine todos los archivos a los que no se haya accedido, ni se
hayan modificado ni cambiado en más de un día.
L /run/fstablink - root root - /etc/fstab

Cree el enlace simbólico /run/fstablink que apunte a /etc/fstab. Nunca purgue


automáticamente esta línea.
Precedencia de archivos de configuración
Los archivos de configuración pueden encontrarse en tres lugares:
 /etc/tmpfiles.d/*.conf

 /run/tmpfiles.d/*.conf

 /usr/lib/tmpfiles.d/*.conf

Los archivos en /usr/lib/tmpfiles.d/ son proporcionados por los paquetes de RPM relevantes,
y no debe editarlos. Los archivos bajo /run/tmpfiles.d/ son archivos volátiles, normalmente
usados por daemons para administrar sus propios archivos temporales de tiempo de ejecución. Los
archivos bajo /etc/tmpfiles.d/ están pensados para que los administradores configuren
ubicaciones temporales personalizadas y anulen los valores predeterminados provistos por el
proveedor.
Si un archivo en /run/tmpfiles.d/ tiene el mismo nombre de archivo que un archivo en
/usr/lib/tmpfiles.d/, se usa el archivo en /run/tmpfiles.d/. Si un archivo en
/etc/tmpfiles.d/ tiene el mismo nombre de archivo que un archivo en /run/tmpfiles.d/ o
/usr/lib/tmpfiles.d/, se usa el archivo en /etc/tmpfiles.d/.
Dadas estas reglas de precedencia, puede reemplazar fácilmente la configuración proporcionada por el
proveedor si copia el archivo relevante en /etc/tmpfiles.d/ y, luego, lo edita. Trabajar de esta
manera garantiza que la configuración proporcionada por el administrador se puede administrar
fácilmente desde un sistema de administración de configuración central, y que no se sobrescriba por
una actualización de un paquete.

Nota
Cuando evalúe configuraciones nuevas o modificadas, puede ser útil solo aplicar los
comandos de un archivo de configuración. Esto se puede lograr si se especifica el
nombre del archivo de configuración en la línea de comandos.

Referencias
Páginas del manual: systemd-tmpfiles(8), tmpfiles.d(5), stat(1), stat(2) y systemd.timer(5).
Ejercicio guiado: Administración de archivos temporales
En este ejercicio, configurará systemd-tmpfiles para cambiar la rapidez con la que elimina los
archivos temporales de /tmp, y también para purgar periódicamente los archivos de otro directorio.

Resultados
Usted deberá ser capaz de realizar lo siguiente:
 Configurar systemd-tmpfiles para eliminar archivos temporales no usados de /tmp.

 Configurar systemd-tmpfiles para purgar periódicamente archivos de otro directorio.

Inicie sesión en workstation como student con la contraseña student.

En workstation, ejecute lab scheduling-tempfiles start para iniciar el ejercicio. Este


script crea los archivos necesarios y asegura la configuración correcta del entorno.
[student@workstation ~]$ lab scheduling-tempfiles start

1. Desde workstation, abra una sesión de SSH en servera como student.


[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$

2. Configure systemd-tmpfiles para limpiar el directorio /tmp para que no contenga


archivos que no se hayan usado en los últimos cinco días. Asegúrese de que la configuración no
se sobrescriba con ninguna actualización del paquete.
2.1.Use el comando sudo -i para cambiar al usuario root.
[student@servera ~]$ sudo -i
[sudo] password for student: student
[root@servera ~]#

2.2.Copie /usr/lib/tmpfiles.d/tmp.conf en /etc/tmpfiles.d/tmp.conf.


[root@servera ~]# cp /usr/lib/tmpfiles.d/tmp.conf \
/etc/tmpfiles.d/tmp.conf

2.3.Busque la línea de configuración en /etc/tmpfiles.d/tmp.conf que se aplica al


directorio /tmp. Reemplace la edad existente de los archivos temporales en esa línea de
configuración con la nueva edad de 5 días. Elimine todas las otras líneas del archivo,
incluidas las comentadas. Puede usar el comando vim /etc/tmpfiles.d/tmp.conf
para editar el archivo de configuración. El archivo /etc/tmpfiles.d/tmp.conf debe
aparecer de la siguiente manera:
q /tmp 1777 root root 5d
En la configuración anterior, el tipo q es idéntico a d e indica a systemd-tmpfiles que
cree el directorio /tmp si no existe. El directorio debe tener los permisos octales
establecidos en 1777. Tanto el usuario propietario como el grupo de /tmp deben ser
root. El directorio /tmp no debe contener los archivos temporales que no se han usado en
los últimos cinco días.
2.4.Use el comando systemd-tmpfiles --clean para verificar que el archivo
/etc/tmpfiles.d/tmp.conf contenga la configuración correcta.
[root@servera ~]# systemd-tmpfiles --clean /etc/tmpfiles.d/tmp.conf

Debido a que el comando anterior no devolvió ningún error, confirma que los ajustes de
configuración son correctos.
3. Agregue una nueva configuración que asegure que el directorio /run/momentary exista con
la propiedad del usuario y del grupo establecida en root. Los permisos octales para el
directorio deben ser 0700. La configuración debe purgar los archivos de este directorio que no
se hayan usado en los últimos 30 segundos.
3.1.Cree el archivo llamado /etc/tmpfiles.d/momentary.conf con el siguiente
contenido. Puede usar el comando vim /etc/tmpfiles.d/momentary.conf para
crear el archivo de configuración.
d /run/momentary 0700 root root 30s

La configuración anterior hace que systemd-tmpfiles asegure que el directorio


/run/momentary exista con sus permisos octales establecidos en 0700. El usuario
propietario y el grupo de /run/momentary deben ser root. Los archivos de este
directorio que no se hayan usado en los últimos 30 segundos se deben purgar.
3.2.Use el comando systemd-tmpfiles --create para verificar que el archivo
/etc/tmpfiles.d/momentary.conf contenga la configuración adecuada. El
comando crea el directorio /run/momentary si aún no existe.
[root@servera ~]# systemd-tmpfiles --create \
/etc/tmpfiles.d/momentary.conf

Debido a que el comando anterior no devolvió ningún error, confirma que los ajustes de
configuración son correctos.
3.3.Use el comando ls para verificar que el directorio /run/momentary se crea con los
permisos, el propietario y el propietario del grupo adecuados.
[root@servera ~]# ls -ld /run/momentary
drwx------. 2 root root 40 Mar 21 16:39 /run/momentary
Tenga en cuenta que el conjunto de permisos octales de /run/momentary es 0700 y que
la propiedad del usuario y del grupo se establece en root.

4. Verifique que cualquier archivo bajo el directorio /run/momentary, no usado en los últimos
30 segundos, se elimina, en función de la configuración de systemd-tmpfiles para el
directorio.
4.1.Use el comando touch para crear un archivo denominado
/run/momentary/testfile.
[root@servera ~]# touch /run/momentary/testfile

4.2.Use el comando sleep para configurar su prompt de shell para que no regrese durante 30
segundos.
[root@servera ~]# sleep 30

4.3.Después de que vuelva a aparecer el prompt de shell, use el comando systemd-


tmpfiles --clean para limpiar archivos obsoletos de /run/momentary, sobre la
base de la regla mencionada en /etc/tmpfiles.d/momentary.conf.
[root@servera ~]# systemd-tmpfiles --clean \
/etc/tmpfiles.d/momentary.conf

El comando anterior elimina /run/momentary/testfile porque el archivo no se usó


durante 30 segundos y debería haberse eliminado según la regla mencionada en
/etc/tmpfiles.d/momentary.conf.

4.4.Use el comando ls -l para verificar que el archivo /run/momentary/testfile no


exista.
[root@servera ~]# ls -l /run/momentary/testfile
ls: cannot access '/run/momentary/testfile': No such file or directory

4.5.Salga de la shell del usuario root y cierre sesión en servera.


[root@servera ~]# exit
logout
[student@servera ~]$ exit
logout
Connection to servera closed.
[student@workstation ~]$

Finalizar
En workstation, ejecute lab scheduling-tempfiles finish para terminar este ejercicio.
Este script elimina los archivos creados durante el ejercicio para garantizar que el entorno quede
limpio.
[student@workstation ~]$ lab scheduling-tempfiles finish

Esto concluye el ejercicio guiado.

Resumen
En este capítulo, aprendió lo siguiente:
 Los trabajos que están programados para ejecutarse una vez en el futuro se llaman trabajos o
tareas diferidos.
 Los trabajos de usuario recurrentes ejecutan las tareas del usuario en una programación de
repetición.
 Los trabajos recurrentes del sistema realizan tareas administrativas en una programación de
repetición que tiene impacto en todo el sistema.
 Las unidades de tipo temporizador de systemd pueden ejecutar tanto los trabajos diferidos
como los recurrentes.

También podría gustarte