systemd (Español)/Timers (Español)

Los temporizadores son archivos de unidad de systemd (Español) cuyo nombre termina en .timer que controlan archivos .service o eventos. Los temporizadores se pueden usar como una alternativa a cron (lea #Como un reemplazo de cron). Los temporizadores tienen soporte incorporado para ejecutar eventos basados en el calendario, eventos de tiempo monotónicos y se pueden ejecutar de forma asíncrona.

Esta traducción de Systemd/Timers fue revisada el 2018-11-21. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Unidades de temporizador

Los temporizadores son archivos de unidades de systemd terminados en un sufijo .timer. Los temporizadores son como cualquier otro arcivo de configuración de unidad y se cargan desde las mismas rutas, pero incluyen una sección que define cuándo y cómo se activa el temporizador. Los temporizadores se definen como uno de estos dos tipos:

• Temporizadores en tiempo real (también conocido como «wallclock timers») se activan con un evento del calendario, de la misma manera que lo hacen los cronjobs. La opción se utiliza para definirlos.
• Temporizadores monotónicos se activan después de un intervalo de tiempo condicionado a un punto de inicio variable. Se detienen si el equipo está temporalmente suspendido o apagado. Hay varios temporizadores monotónicos diferentes, pero todos tienen la forma: . Los temporizadores monotónicos comunes incluyen OnBootSec y .

Para obtener una explicación completa de las opciones del temporizador, consulte systemd.timer(5). La sintaxis de los argumentos para los eventos del calendario y los intervalos de tiempo se definen en .

Unidad de servicio

Para cada archivo .timer, existe un archivo .service coincidente (por ejemplo, y foo.service). El archivo .timer activa y controla el archivo .service. El archivo .service no requiere una sección ya que son las unidades de temporizador las que se activan. Si es necesario, es posible controlar una unidad con un nombre diferente usando la opción en la sección del archivo temporizador.

Gestión

Para usar una unidad temporizador active e inicie la misma como cualquier otra unidad (recuerde agregar el sufijo .timer). Para ver todos los temporizadores iniciados, ejecute:

Ejemplos

Un archivo de unidad de servicio se puede programar con un temporizador listo para usar. Los siguientes ejemplos programan que el servicio, foo.service, se ejecutará con el temporizador correspondiente llamado .

Temporizador monotónico

Un temporizador que se iniciará 15 minutos después del arranque y nuevamente cada semana mientras el sistema se está ejecutando.

Temporizador en tiempo real

Un temporizador que comienza una vez a la semana (a las 12:00 AM del lunes). Cuando se activa, activa el servicio inmediatamente si se perdió la última hora de inicio (opción ), por ejemplo, debido a que el sistema estaba apagado:

/etc/systemd/system/foo.timer

[Unit]
Description=Run foo weekly

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target

Cuando se requieren fechas y horas más específicas, los eventos de utilizan el siguiente formato: es decir: Se puede usar un asterisco para especificar cualquier valor y se pueden usar comas para listar posibles valores. Dos valores separados por indica un rango contiguo.

En el ejemplo siguiente, el servicio se ejecuta los primeros cuatro días de cada mes a las 12:00 PM, pero solo si ese día es lunes o martes.

OnCalendar=Mon,Tue *-*-01..04 12:00:00

Para ejecutar un servicio el primer sábado de cada mes, use:

OnCalendar=Sat *-*-1..7 18:00:00

Al usar , se debe especificar, al menos, un día de la semana. Si quiere algo para ejecutar todos los días a las 4 AM, utilice:

 OnCalendar=*-*-* 4:00:00

Para ejecutar un servicio en diferentes momentos, puede especificarse más de una vez. En el siguiente ejemplo, el servicio se ejecuta a las 22:30 los días entre fines de semana y a las 20:00 los fines de semana.

 OnCalendar=Mon..Fri 22:30
 OnCalendar=Sat,Sun 20:00

Dispone de más información en .

Unidades .timer transitorias

Se puede utilizar para crear unidades .timer transitorias. Es decir, se puede configurar una orden para que se ejecute a una hora específica sin tener un archivo de servicio. Por ejemplo, la siguiente orden muestra un archivo después de 30 segundos:

# systemd-run --on-active=30 /bin/touch /tmp/foo

También se puede especificar un archivo de servicio preexistente que no tiene un archivo de temporizador. Por ejemplo, lo siguiente inicia la unidad systemd llamada someunit.service después de que hayan transcurrido 12 horas y media:

# systemd-run --on-active="12h 30m" --unit someunit.service

Véase para más información y ejemplos.

Como un reemplazo de cron

Aunque cron es posiblemente el planificador de trabajos más conocido, los temporizadores de systemd pueden ser una alternativa.

Beneficios

Los principales beneficios de usar temporizadores provienen del hecho de que cada trabajo tiene su propio servicio systemd. Algunos de estos beneficios son:

• Los trabajos pueden iniciarse fácilmente independientemente de sus temporizadores. Esto simplifica la depuración de errores.
• Cada trabajo puede configurarse para ejecutarse en un entorno específico (consulte systemd.exec(5)).
• Los trabajos se pueden adjuntar a grupos de control.
• Los trabajos se pueden configurar para que dependan de otras unidades de systemd.
• Los trabajos se registran en el journal de systemd para una fácil depuración de errores.

Advertencias

Algunas cosas que son fáciles de hacer con cron son difíciles de hacer solo con unidades de temporizador:

• Creación: para configurar un trabajo temporizado con systemd necesita crear dos archivos y ejecutar órdenes , en comparación con crontab que basta con agregar una sola línea.
• Correos electrónicos: no hay un equivalente incorporado a de cron para enviar correos electrónicos en el caso de que falle el trabajo. Consulte la siguiente sección para ver un ejemplo de cómo configurar una funcionalidad similar utilizando .

MAILTO

Puede configurar systemd para enviar un correo electrónico cuando falla una unidad. Cron envía un correo a si el trabajo da una salida stdout o stderr, aunque muchos trabajos se pueden configurar para generar solo un error. Primero, necesita dos archivos: un ejecutable para enviar el correo y un .service para iniciar el ejecutable. Para este ejemplo, el ejecutable es solo un script de intérprete de órdenes que usa :

Cualquiera que sea el ejecutable que utilice, probablemente debería tomar, al menos, dos argumentos, como lo hace este script de intérprete de órdenes: la dirección a la que enviar el correo y el archivo de la unidad para obtener el estado (de no entregado). El .service que creamos pasará estos argumentos:

Donde es el usuario que recibe el correo electrónico y address es la dirección de correo electrónico de ese usuario. Aunque el receptor esté codificado, el archivo de unidad sobre el que se informa se pasa como un parámetro de instancia, por lo que este servicio puede enviar correo electrónico para muchas otras unidades. En este punto, puede iniciar para verificar que puede recibir los correos electrónicos.

Luego simplemente edite el servicio para el que desea correos electrónicos y agregue a la sección [Unit]. pasa el nombre de la unidad a la plantilla.

Utilizar un crontab

Se pueden solucionar varias de las advertencias descritas arriba mediante la instalación de un paquete que pase un crontab tradicional para configurar los temporizadores. y son dos de estos paquetes. Estos pueden proporcionar la característica que falta.

Además, al igual que con crontabs, se puede obtener una vista unificada de todos los trabajos programados con . Véase #Gestión.

Véase también

• systemd.timer(5)
• Página wiki del Proyecto Fedora sobre los temporizadores basados en el calendario de systemd
• Sección de la wiki de Gentoo sobre los servicios temporizadores de systemd