GNU/Linux >> Tutoriales Linux >  >> Linux

Use temporizadores systemd en lugar de cronjobs

Estoy en el proceso de convertir mis trabajos cron a temporizadores systemd. He usado temporizadores durante algunos años, pero por lo general, aprendí lo suficiente para realizar la tarea en la que estaba trabajando. Mientras investigaba para esta serie de systemd, aprendí que los temporizadores de systemd tienen algunas capacidades muy interesantes.

Al igual que los trabajos cron, los temporizadores systemd pueden desencadenar eventos (programas y scripts de shell) en intervalos de tiempo específicos, como una vez al día, en un día específico del mes (quizás solo si es lunes) o cada 15 minutos durante el horario comercial. de 8am a 6pm. Los temporizadores también pueden hacer algunas cosas que los trabajos cron no pueden. Por ejemplo, un temporizador puede activar una secuencia de comandos o un programa para que se ejecute una cantidad específica de tiempo después de un evento como el arranque, el inicio, la finalización de una tarea anterior o incluso la finalización anterior de la unidad de servicio llamada por el temporizador.

Temporizadores de mantenimiento del sistema

Cuando se instala Fedora o cualquier distribución basada en systemd en un sistema nuevo, se crean varios temporizadores que forman parte de los procedimientos de mantenimiento del sistema que ocurren en el fondo de cualquier host Linux. Estos temporizadores activan eventos necesarios para tareas de mantenimiento comunes, como actualizar bases de datos del sistema, limpiar directorios temporales, rotar archivos de registro y más.

Como ejemplo, veré algunos de los temporizadores en mi estación de trabajo principal usando el systemctl status *timer Comando para enumerar todos los temporizadores en mi host. El símbolo de asterisco funciona igual que para la acumulación de archivos, por lo que este comando enumera todas las unidades de temporizador systemd:

[root@testvm1 ~]# systemctl status *timer 
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.

Cada temporizador tiene al menos seis líneas de información asociadas:

  • La primera línea tiene el nombre del archivo del temporizador y una breve descripción de su propósito.
  • La segunda línea muestra el estado del temporizador, si está cargado, la ruta completa al archivo de la unidad del temporizador y el preajuste del proveedor.
  • La tercera línea indica su estado activo, que incluye la fecha y la hora en que se activó el temporizador.
  • La cuarta línea contiene la fecha y la hora en que se activará el temporizador a continuación y un tiempo aproximado hasta que ocurra la activación.
  • La quinta línea muestra el nombre del evento o el servicio que activa el temporizador.
  • Algunos (pero no todos) los archivos de unidad systemd tienen punteros a la documentación relevante. Tres de los temporizadores en la salida de mi máquina virtual tienen punteros a la documentación. Este es un buen dato (pero opcional).
  • La línea final es la entrada de diario de la instancia más reciente del servicio activado por el temporizador.

Dependiendo de su anfitrión, probablemente tendrá un conjunto diferente de temporizadores.

Crear un temporizador

Aunque podemos deconstruir uno o más de los temporizadores existentes para aprender cómo funcionan, creemos nuestra propia unidad de servicio y una unidad de temporizador para activarlo. Usaremos un ejemplo bastante trivial para mantener esto simple. Una vez que hayamos terminado con esto, será más fácil entender cómo funcionan los otros temporizadores y determinar qué están haciendo.

Primero, cree un servicio simple que ejecute algo básico, como free dominio. Por ejemplo, es posible que desee controlar la memoria libre a intervalos regulares. Cree el siguiente myMonitor.service archivo de unidad en el /etc/systemd/system directorio. No necesita ser ejecutable:

# This service unit is for testing timer units 
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

Ahora veamos el estado y probemos nuestra unidad de servicio para asegurarnos de que funciona como esperamos.

[root@testvm1 system]# systemctl status myMonitor.service 
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#

¿Dónde está la salida? Por defecto, la salida estándar (STDOUT ) de los programas ejecutados por las unidades de servicio de systemd se envía al diario de systemd, lo que deja un registro que puede ver ahora o más adelante, hasta cierto punto. (Examinaré el registro en diario y las estrategias de retención de systemd en un artículo futuro de esta serie). Mire el diario específicamente para su unidad de servicio y solo para hoy. El -S opción, que es la versión corta de --since , le permite especificar el período de tiempo que el journalctl La herramienta debe buscar entradas. Esto no se debe a que no le importen los resultados anteriores (en este caso, no habrá ninguno), es para acortar el tiempo de búsqueda si su host ha estado funcionando durante mucho tiempo y ha acumulado una gran cantidad de entradas. en el diario:

[root@testvm1 system]# journalctl -S today -u myMonitor.service 
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#

Una tarea desencadenada por un servicio puede ser un solo programa, una serie de programas o una secuencia de comandos escrita en cualquier lenguaje de secuencias de comandos. Agregue otra tarea al servicio agregando la siguiente línea al final del [Service] sección de myMonitor.service archivo de unidad:

ExecStart=/usr/bin/lsblk

Vuelva a iniciar el servicio y consulte el diario para ver los resultados, que deberían tener este aspecto. Debería ver los resultados de ambos comandos en el diario:

Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

Ahora que sabe que su servicio funciona como se espera, cree el archivo de la unidad del temporizador, myMonitor.timer file en /etc/systemd/system y agregue lo siguiente:

# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

El OnCalendar especificación de tiempo en el archivo myMonitor.timer file , *-*-* *:*:00 , debería activar el temporizador para ejecutar myMonitor.service unidad cada minuto. Exploraré OnCalendar configuración un poco más adelante en este artículo.

Por ahora, observe cualquier entrada de diario relacionada con la ejecución de su servicio cuando el temporizador lo active. También puede seguir el temporizador, pero seguir el servicio le permite ver los resultados casi en tiempo real. Ejecute journalctl con el -f (seguir) opción:

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

Inicie pero no habilite el temporizador y vea qué sucede después de que se ejecuta por un tiempo:

[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#

Un resultado aparece de inmediato, y los siguientes vienen en intervalos de un minuto. Mire el diario durante unos minutos y vea si nota las mismas cosas que yo:

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

Asegúrese de verificar el estado tanto del temporizador como del servicio.

Más sobre administradores de sistemas

  • Habilitar el blog de administrador del sistema
  • La empresa automatizada:una guía para administrar TI con automatización
  • Libro electrónico:Automatización de Ansible para administradores de sistemas
  • Historias del campo:una guía del administrador de sistemas para la automatización de TI
  • eBook:Una guía de Kubernetes para SRE y administradores de sistemas
  • Últimos artículos de administrador de sistemas

Probablemente hayas notado al menos dos cosas en el diario. Primero, no necesita hacer nada especial para causar el STDOUT desde el ExecStart disparadores en myMonitor.service unidad que se almacenará en el diario. Todo eso es parte del uso de systemd para ejecutar servicios. Sin embargo, significa que es posible que deba tener cuidado al ejecutar scripts desde una unidad de servicio y cuánto STDOUT generan.

La segunda cosa es que el temporizador no se activa exactamente en el minuto a:00 segundos o incluso exactamente un minuto desde la instancia anterior. Esto es intencional, pero puede anularse si es necesario (o si simplemente ofende la sensibilidad de su administrador de sistemas).

El motivo de este comportamiento es evitar que varios servicios se activen exactamente al mismo tiempo. Por ejemplo, puede usar especificaciones de tiempo como Semanal, Diaria y más. Todos estos accesos directos están definidos para activarse a las 00:00:00 horas del día en que se activan. Cuando se especifican varios temporizadores de esta manera, existe una gran probabilidad de que intenten iniciarse simultáneamente.

Los temporizadores systemd están diseñados intencionalmente para activarse de forma algo aleatoria alrededor del tiempo especificado para tratar de evitar activaciones simultáneas. Se activan de forma semialeatoria dentro de una ventana de tiempo que comienza a la hora de activación especificada y finaliza a la hora especificada más un minuto. Este tiempo de activación se mantiene en una posición estable con respecto a todas las demás unidades de temporizador definidas, de acuerdo con el systemd.timer página de manual Puede ver en las entradas del diario anteriores que el temporizador se activó inmediatamente cuando comenzó y luego aproximadamente 46 o 47 segundos después de cada minuto.

La mayoría de las veces, estos tiempos de activación probabilísticos están bien. Al programar tareas como la ejecución de copias de seguridad, siempre que se ejecuten fuera del horario laboral, no habrá problemas. Un administrador de sistemas puede seleccionar una hora de inicio determinista, como 01:05:00 en una especificación típica de trabajo cron, para que no entre en conflicto con otras tareas, pero hay una amplia gama de valores de tiempo que lo lograrán. Un poco de aleatoriedad de un minuto en una hora de inicio suele ser irrelevante.

Sin embargo, para algunas tareas, los tiempos de activación exactos son un requisito absoluto. Para ellos, puede especificar una mayor precisión de intervalo de tiempo de activación (dentro de un microsegundo) agregando una declaración como esta al Timer sección del archivo de la unidad del temporizador:

AccuracySec=1us

Los intervalos de tiempo se pueden utilizar para especificar la precisión deseada, así como para definir intervalos de tiempo para eventos repetidos o únicos. Reconoce las siguientes unidades:

  • usec, nosotros, µs
  • mseg, ms
  • segundos, segundo, seg, s
  • minutos, minuto, min, m
  • horas, hora, h, h
  • días, día, d
  • semanas, semana, w
  • meses, mes, M (definido como 30,44 días)
  • años, año, y (definido como 365,25 días)

Todos los temporizadores predeterminados en /usr/lib/systemd/system especifique un rango mucho más grande para la precisión porque los tiempos exactos no son críticos. Mire algunas de las especificaciones en los temporizadores creados por el sistema:

[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#

Vea el contenido completo de algunos de los archivos de la unidad del temporizador en /usr/lib/systemd/system directorio para ver cómo se construyen.

No es necesario que habilite el temporizador en este experimento para activarlo en el momento del arranque, pero el comando para hacerlo sería:

# systemctl enable myMonitor.timer

Los archivos de unidad que creó no necesitan ser ejecutables. Tampoco habilitó la unidad de servicio porque la activa el temporizador. Todavía puede activar la unidad de servicio manualmente desde la línea de comando, si así lo desea. Prueba eso y observa el diario.

Consulte las páginas man de systemd.timer y systemd.time para obtener más información sobre la precisión del temporizador, las especificaciones de tiempo de eventos y los eventos desencadenantes.

Tipos de temporizador

Los temporizadores systemd tienen otras capacidades que no se encuentran en cron, que se activan solo en fechas y horas específicas, repetitivas y en tiempo real. Los temporizadores de systemd se pueden configurar para que se activen en función de los cambios de estado en otras unidades de systemd. Por ejemplo, se puede configurar un temporizador para activar un tiempo transcurrido específico después del inicio del sistema, después del inicio o después de que se active una unidad de servicio definida. Estos se denominan temporizadores monotónicos. Monotónico se refiere a un conteo o secuencia que aumenta continuamente. Estos temporizadores no son persistentes porque se reinician después de cada arranque.

La Tabla 1 enumera los temporizadores monotónicos junto con una breve definición de cada uno, así como el OnCalendar timer, que no es monótono y se utiliza para especificar tiempos futuros que pueden o no ser repetitivos. Esta información se deriva del systemd.timer página de manual con algunos cambios menores.

Tabla 1:definiciones de temporizador systemd

Los temporizadores monotónicos pueden usar los mismos nombres de atajos para sus intervalos de tiempo que AccuracySec declaración mencionada anteriormente, pero systemd normaliza esos nombres a segundos. Por ejemplo, es posible que desee especificar un temporizador que active un evento una vez, cinco días después de que se inicie el sistema; que podría parecerse a:OnBootSec=5d . Si el host arrancó en 2020-06-15 09:45:27 , el temporizador se activaría en 2020-06-20 09:45:27 o dentro de un minuto después.

Especificaciones de eventos del calendario

Las especificaciones de los eventos del calendario son una parte clave para activar los temporizadores en los momentos repetitivos deseados. Comience mirando algunas especificaciones utilizadas con el OnCalendar ajuste.

systemd y sus temporizadores usan un estilo diferente para las especificaciones de fecha y hora que el formato usado en crontab. Es más flexible que crontab y permite fechas y horas difusas a la manera de at dominio. También debe ser lo suficientemente familiar para que sea fácil de entender.

El formato básico para los temporizadores systemd usando OnCalendar= es DOW YYYY-MM-DD HH:MM:SS . DOW (día de la semana) es opcional, y otros campos pueden usar un asterisco (*) para hacer coincidir cualquier valor para esa posición. Todos los formularios de tiempo del calendario se convierten a un formulario normalizado. Si no se especifica la hora, se supone que es 00:00:00. Si no se especifica la fecha pero sí la hora, el próximo partido podría ser hoy o mañana, según la hora actual. Se pueden utilizar nombres o números para el mes y el día de la semana. Se pueden especificar listas separadas por comas de cada unidad. Los rangos de unidades se pueden especificar con .. entre los valores inicial y final.

Hay un par de opciones interesantes para especificar fechas. La Tilde (~) se puede usar para especificar el último día del mes o un número específico de días antes del último día del mes. El "/" se puede utilizar para especificar un día de la semana como modificador.

Estos son algunos ejemplos de algunas especificaciones de tiempo típicas utilizadas en OnCalendar declaraciones.

Temporizador Monotónico Definición
OnActiveSec= X Esto define un temporizador relativo al momento en que se activa el temporizador.
OnBootSec= X Esto define un temporizador relativo al arranque de la máquina.
OnStartupSec= X Esto define un temporizador relativo a cuando el administrador de servicios se inicia por primera vez. Para las unidades de temporizador del sistema, esto es muy similar a OnBootSec= , ya que el administrador de servicios del sistema generalmente comienza muy temprano en el arranque. Es principalmente útil cuando se configura en unidades que se ejecutan en el administrador de servicios por usuario, ya que el administrador de servicios de usuario generalmente comienza solo con el primer inicio de sesión, no durante el arranque.
OnUnitActiveSec= X Esto define un temporizador relativo a cuándo se activó por última vez el temporizador que se va a activar.
OnUnitInactiveSec= X Esto define un temporizador relativo a cuándo se desactivó por última vez el temporizador que se va a activar.
OnCalendar=   Esto define temporizadores en tiempo real (es decir, reloj de pared) con expresiones de eventos de calendario. Ver systemd.time(7) para obtener más información sobre la sintaxis de las expresiones de eventos de calendario. De lo contrario, la semántica es similar a OnActiveSec= y ajustes relacionados. Este temporizador es el más parecido a los que se usan con el servicio cron.

Tabla 2:Muestra OnCalendar especificaciones del evento

Especificaciones del calendario de prueba

systemd proporciona una excelente herramienta para validar y examinar las especificaciones de eventos de tiempo de calendario en un temporizador. El systemd-analyze calendar La herramienta analiza la especificación de un evento de tiempo de calendario y proporciona la forma normalizada, así como otra información interesante, como la fecha y la hora del próximo "transcurso", es decir, la coincidencia, y la cantidad aproximada de tiempo antes de que se alcance el tiempo de activación.

Primero, mire una fecha en el futuro sin tiempo (tenga en cuenta que los tiempos para Next elapse y UTC diferirá según su zona horaria local):

[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Now add a time. In this example, the date and time are analyzed separately as non-related entities:

[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

To analyze the date and time as a single unit, enclose them together in quotes. Be sure to remove the quotes when using them in the OnCalendar= event specification in a timer unit or you will get errors:

[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

Now test the entries in Table 2. I like the last one, especially:

[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#

Let’s look at one example in which we list the next five elapses for the timestamp expression.

[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

This should give you enough information to start testing your OnCalendar time specifications. The systemd-analyze tool can be used for other interesting analyses, which I will begin to explore in the next article in this series.

Resumen

systemd timers can be used to perform the same kinds of tasks as the cron tool but offer more flexibility in terms of the calendar and monotonic time specifications for triggering events.

Even though the service unit you created for this experiment is usually triggered by the timer, you can also use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a single timer; these can be Bash scripts or Linux utility programs. You can run the service triggered by the timer to run all the scripts, or you can run individual scripts as needed.

I will explore systemd's use of time and time specifications in much more detail in the next article.

I have not yet seen any indication that cron and at will be deprecated. I hope that does not happen because at , at least, is much easier to use for one-off task scheduling than systemd timers.

Resources

There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.

  • The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
  • The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
  • For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
  • Linux.com's "More systemd fun" offers more advanced systemd information and tips.

There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.

  • Rethinking PID 1
  • systemd for Administrators, Part I
  • systemd for Administrators, Part II
  • systemd for Administrators, Part III
  • systemd for Administrators, Part IV
  • systemd for Administrators, Part V
  • systemd for Administrators, Part VI
  • systemd for Administrators, Part VII
  • systemd for Administrators, Part VIII
  • systemd for Administrators, Part IX
  • systemd for Administrators, Part X
  • systemd for Administrators, Part XI

Linux
  1. ¿Qué debo usar en lugar de windows.h en Linux?

  2. ¿Por qué se debe evitar eval en Bash y qué debo usar en su lugar?

  3. Cómo usar con éxito el protocolo RDAP en lugar de whois

  4. usando temporizadores systemd en lugar de cron

  5. Uso de CPUQuota en systemd

Por qué uso exa en lugar de ls en Linux

¿No amas las diferencias? Use Meld en su lugar

Linux vs Mac OS:15 razones por las que usar Linux en lugar de Mac OS

Cómo usar IPTables en lugar de firewalld para Fedora 30-31-32

Cómo usar journalctl para ver y manipular registros de Systemd

¿Puede Windows usar un shell de Linux en lugar de cmd?

    Especificación de eventos del calendario Descripción
    DOW AAAA-MM-DD HH:MM:SS  
    *-*-* 00:15:30 Todos los días de cada mes de cada año a los 15 minutos y 30 segundos después de la medianoche
    Semanal Todos los lunes a las 00:00:00
    Lun *-*-* 00:00:00 Igual que semanal
    lunes Igual que semanal
    miércoles 2020-*-* Todos los miércoles de 2020 a las 00:00:00
    lunes a viernes de 2021-*-* Todos los días de la semana en 2021 a las 00:00:00
    2022-6,7,8-1,15 01:15:00 Los días 1 y 15 de junio, julio y agosto de 2022 a las 01:15:00 am
    Lun *-05~03 La próxima aparición de un lunes de mayo de cualquier año que también sea el tercer día desde el final del mes.
    lunes a viernes *-08~04 El cuarto día anterior al final de agosto para los años en los que también cae en un día laborable.
    *-05~03/2 El tercer día desde el final del mes de mayo y luego nuevamente dos días después. Se repite todos los años. Tenga en cuenta que esta expresión usa la tilde (~).
    *-05-03/2 El tercer día del mes de mayo y luego cada 2 días durante el resto de mayo. Se repite todos los años. Tenga en cuenta que esta expresión utiliza el guión (-).