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/lsblkVuelva 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=1usLos 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.timerLos 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.
| 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. |
| Especificación de eventos del calendario | Descripción |
|---|---|
| DOW AAAA-MM-DD HH:MM:SS | |
| 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 |
| 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. |
| 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 (~). | |
| 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 (-). |