Phenquestions
Para comprender cómo systemd puede serle útil allí, tomaré un ejemplo.
¿Qué trampas te evitarán los temporizadores systemd??
Si alguna vez posee una máquina con datos que le interesan, querrá tener una copia de sus datos en otro lugar, probablemente más seguro. Si administra un servidor, es obligatorio: después de todo, ¿cómo se recuperará si su disco duro falla y no le permitirá recuperar ningún dato??
Entonces, como persona responsable, configura la copia de seguridad cada semana o todos los días. Puede configurarlo usando cron, lo programa a las 4:24 a.m., pero aquí comienza el problema: ¿qué pasa si su servidor se apaga de 4:10 a.m. a 4:30 a.m. por cualquier motivo??
Bueno, es probable que cron simplemente omita esa copia de seguridad. Esto podría ser crítico si eso sucede a menudo y en silencio o si su código se basa en el hecho de que se ejecuta y, de lo contrario, puede fallar. Generalmente, esto sucede cuando configura una tarea de limpieza a través de cron y no se inicia. De repente, su código puede tener espacio insuficiente para continuar y se romperá - Es triste, muy triste situación, ¿verdad Sr. Elton John?.
Sin embargo, si un lanzamiento perdido puede ser un problema, imagina un segundo - wow, John Lennon ahora? - que tu tarea es demasiado lenta. Si su tarea está configurada para ejecutarse cada 10 minutos pero tarda 15 minutos en completarse, cron o Windows iniciarán felizmente otra tarea incluso si la tarea actual aún no se ha terminado, por lo que tendrá 2 instancias de su tarea ejecutándose simultáneamente , Cuál es el receta perfecta por desastre. Cuando un programa se ejecuta al mismo tiempo y no está diseñado para hacerlo, es muy probable que corrompa archivos, otros softwares y bases de datos - y su servidor se convierte de repente en un barco que se hunde como el Titanic.
De acuerdo, tal vez estoy yendo demasiado lejos con Titanic, pero entiendes la idea. Si bien systemd no pudo haber hecho mucho para salvar este barco, puede ayudarlo con todas estas deficiencias y garantizarle unas vacaciones navideñas más largas gracias a los errores que le evitará. Ahora es el momento de aprender a configurar temporizadores systemd.
Cómo programar una copia de seguridad automática del servidor?
En primer lugar, los temporizadores systemd activan un servicio systemd, por lo que antes de programar su tarea, primero deberá convertirla en un servicio. Afortunadamente, he escrito una guía para crear el servicio systemd, de esta manera le presentará la forma de trabajar de systemd. Deberías leerlo antes de continuar. A menos que si tu exactamente sabe lo que está haciendo, su archivo de servicio systemd debería no contener cualquier configuración WantedBy =. Si desea iniciar su servicio en un momento específico, probablemente no desee iniciarlo en el arranque.
Gracias al sistema de servicio systemd, es imposible tener varias instancias de su tarea ejecutándose por error: si una tarea ya se está ejecutando, simplemente omitirá ese inicio y dejará que la tarea que se está ejecutando actualmente termine su trabajo.
Una vez que tenga un servicio systemd para programar, cree un archivo con el mismo nombre de archivo que su servicio, excepto que debe terminar con .temporizador en lugar de .Servicio. En nuestro ejemplo de copia de seguridad automatizada, el servicio sería una copia de seguridad automática.servicio y el temporizador sería de respaldo automático.Temporizador. Ambos archivos deben estar en el mismo directorio. Como te dije en el artículo del servicio systemd, te recomiendo que escribas estos archivos en un lugar normal como tu directorio de inicio y luego, los copies en una carpeta systemd, una vez que hayas terminado tus ediciones.
Entonces, déjame mostrarte cómo se ve nuestro archivo de temporizador:
[Unidad]Descripción = Programar copias de seguridad fuera de las horas pico
[Temporizador]
OnCalendar = * - * - * 03:00:00
RandomizedDelaySec = 7200
Persistente = verdadero
[Instalar en pc]
WantedBy = temporizadores.objetivo
Al igual que en los servicios de systemd, hay 3 secciones. [Unidad] o [Instalar] funcionan exactamente igual que se explica en mi artículo de servicios de systemd. Tenga en cuenta que WantedBy = es importante aquí porque los temporizadores pueden iniciarse o detenerse, por lo que si no le dice a systemd que inicie su temporizador durante el arranque, nunca se activará. temporizadores.target es un target systemd especial para temporizadores.
Ahora, la sección [Temporizador]. En su interior, encontrará todas las configuraciones relacionadas con cuándo debería activarse el temporizador. Para nuestra copia de seguridad automática, le he dicho a systemd que la ejecute entre las 3 a. M. Y las 5 a. M. En la zona horaria del servidor. La hora exacta es aleatoria cada día.
OnCalendar = establece el temporizador relacionado con la hora de su servidor (reloj de pared), como todos los domingos a la 1 p.m. Si ha usado cron anteriormente, debería estar realmente familiarizado con esta sintaxis. Sin embargo, tiene algunos beneficios adicionales.
Por ejemplo, si desea que suceda algo cada hora, puede hacer lo siguiente:
OnCalendar = cada horay diariamente:
OnCalendar = diarioDe hecho, admite todos los siguientes valores:
- minuciosamente
- cada hora
- diario
- mensual
- semanal
- anual
- trimestral
- semi anualmente
Sin embargo, existe un problema con estas palabras clave: por ejemplo, todos los días se activan siempre a medianoche, que suele ser una hora pico en los sistemas informáticos. Es por eso que se recomienda usar RandomizedDelaySec = (su uso se especifica a continuación). De todos modos, para la copia de seguridad no es una buena opción: la medianoche no es fuera de las horas pico, es más bien al revés. Por lo tanto, debemos establecer con mayor precisión cuándo queremos que se inicie esa tarea.
Si desea más control, puede escribir una fecha como 2018-12-06 12:49:37. Bueno, si eres así de específico, activarás el temporizador una vez. Para que sea recurrente, reemplazará cualquiera de estos elementos por * asterisco.
OnCalendar = * - * - * 03:00:00Como puede ver arriba, en nuestro ejemplo de copia de seguridad, toda la parte de la fecha es * - * - *, lo que significa que debería ocurrir todos los días de cada mes de cada año. Ahora si lo hace:
OnCalendar = * - 12-25 03:00:00Luego se ejecuta cada 25 de diciembre a las 3 a. M. Temporizador systemd perfecto para Santa Claus - incluso si dudo que alguna vez necesite uno! Entonces, el asterisco agrega recurrencia donde lo pones. Si lo pone en el campo de año, significa "todos los años", etc.
Finalmente, puede agregar UTC al final de la línea para usar la hora UTC en lugar de la zona horaria local. Por ejemplo, algunos servicios restablecen sus cuotas de API a la medianoche, pero para evitar cualquier sesgo de zona horaria, usa UTC. Entonces, para tales tareas, haría:
OnCalendar = UTC diarioAhora, solucionemos otro problema: las horas punta. systemd también tiene un escenario para luchar contra eso.
RandomizedDelaySec = permite retrasar la tarea de una cantidad de tiempo aleatoria. El valor es el número máximo de segundos que el temporizador retrasará. Está diseñado específicamente para tales casos. Recuerda que en systemd, todos los días siempre se dispara a la medianoche? Bueno, semanalmente siempre se activa el lunes a la medianoche y anual se activa el 1 de enero a la medianoche, uno de los peores picos del año con cortes de red en todas partes. Ciertamente no quieres que eso suceda.
Al agregar un retraso, elimina ese problema: retrasará automáticamente en un momento desconocido su tarea. La aleatoriedad aquí es importante porque es mucho más probable que sea incluso cuando es aleatoria y una carga uniforme permite optimizar mejor sus tareas.
Supongamos que necesita ejecutar sus tareas alrededor de las 7 a.m.por la mañana, pero desea permitir un pequeño retraso de un máximo de 15 minutos, lo haría así:
RandomizedDelaySec = 900Eso debería ser suficiente para retrasos. A veces, incluso retrasos de milisegundos son suficientes para evitar picos no deseados.
Persistente = se encarga de los disparadores del temporizador perdidos. ¿Qué pasa si su servidor se apaga durante la noche?? Bueno, la copia de seguridad nunca se dispararía. Establecerlo en verdadero permite que systemd lo ejecute en el próximo arranque en tales casos. De esta forma sabrá de una forma u otra que se ejecutará la tarea del temporizador. Su uso es simple, solo haz esto:
Persistente = verdaderoSin embargo, esto tiene un inconveniente que es realmente difícil de evitar de todos modos: cuando se pierden varias tareas de diferentes temporizadores, todas se ejecutarán en el arranque y ralentizarán ese arranque. En mi opinión, eso es mucho mejor que si nunca se ejecuta y después de todo eso es normal, el momento más apropiado para ejecutar el temporizador es cuando está programado, luego probablemente será inapropiado de todos modos.
OnBootSec = es la última opción que te mostraré (pero no menos importante). Es si desea activar un temporizador algún tiempo después del arranque en lugar de basarse en el calendario. Por ejemplo, si necesita verificar en el inicio si su servidor se inicia correctamente y funciona según lo previsto, puede escribir un servicio de verificación y usar esa configuración del temporizador para activarlo después de que el sistema haya tenido tiempo suficiente para iniciarse.
Digamos que el sistema necesita 3 minutos para arrancar, podría hacer:
OnBootSec = 180Y a pesar de su nombre, también puedes hacer:
OnBootSec = 3 minutosSi precisa tanto OnBootSec = como OnCalendar =, iniciará el servicio cada vez que ocurra alguno de estos 2 eventos.
Bien, ahora es el momento de guardar su archivo, copiarlo en la carpeta del sistema si siguió mi consejo anterior y probar si su temporizador funciona correctamente.
Habilite su nuevo temporizador y monitoreo
Para probar su nuevo temporizador, debe decirle a systemd que agregó un nuevo temporizador, por lo que debe escribir este comando:
$ sudo systemctl daemon-reloadAhora, systemd tendrá en cuenta su nuevo temporizador y observará de cerca cuándo ejecutar su tarea. Como systemd siempre se está ejecutando, después de todo, es uno de los mejores candidatos para administrar y ejecutar sus tareas programadas.
Sin embargo, una cosa que puede encontrar contraria a la intuición: un temporizador está deshabilitado de forma predeterminada. Para habilitarlo, debe hacer este comando:
$ sudo systemctl enable --ahora copia de seguridad automática.TemporizadorEntonces probablemente querrá ver si su temporizador actúa como se esperaba. Buenas noticias: systemd incluso tiene la amabilidad de tener un comando que le indique cuándo se lanzó por última vez y cuándo está programado el próximo lanzamiento (excepto si el temporizador está configurado para ejecutarse solo en el inicio, ya que systemd no sabe cuándo el sistema se iniciará nuevamente, obviamente). Aquí está ese comando:
$ systemctl status copia de seguridad automática.TemporizadorFinalmente, cuando ya no necesite el temporizador, también puede desactivarlo:
$ sudo systemctl deshabilitar --ahora copia de seguridad automática.TemporizadorConclusión
Con los temporizadores systemd, la gestión de las tareas programadas pasa al siguiente nivel: honestamente, personalmente creo que las tareas programadas deberían haber sido así desde hace años.
Oh, una pequeña sorpresa para ti: todos los temporizadores systemd se registran en un sistema bien estructurado con filtrado, rotación de registros y todo lo similar. Así que te invito a ver cómo puedes ver los registros sobre tus tareas programadas!
