Ubuntu 16.04: las actualizaciones desatendidas se ejecutan en momentos aleatorios

He configurado actualizaciones desatendidas para instalar paquetes de seguridad y notificar por correo cuando lo haga.

He notado que la instalación ocurre en momentos muy aleatorios. Sé que las últimas versiones agregaron un retraso aleatorio de hasta 30 minutos a partir del tiempo de ejecución cron.daily.

Sin embargo, los retrasos que estoy experimentando son mucho mayores que eso. Veo actualizaciones desatendidas ejecutándose a las 9 a.m., 3 p.m., 12 a.m. ... Los registros muestran lo mismo, por lo que no es solo la entrega del correo electrónico lo que lleva más tiempo.

La tarea de actualizaciones desatendidas es la primera en cron.daily, lo que significa que no hay ninguna tarea previa con tiempos de ejecución enormes.

¿Alguien ha experimentado algo similar?

16.04 cron unattended-upgrades

— daniel f.
fuente

El comportamiento aleatorio es deliberado: suavizar la demanda en lugar de millones de sistemas que trabajan algunos espejos a la misma hora todos los días. Los usuarios de escritorio normales no deberían notar el comportamiento en absoluto. Algunos usuarios empresariales desean cambiar el comportamiento a algo un poco más predecible, y ciertamente son bienvenidos a hacerlo.

— user535733

Sí, la razón detrás de esta elección es clara. Es solo que este comportamiento es inaceptable para los sistemas de producción. En el momento en que hice esta pregunta, este comportamiento (y la solución) no estaba documentado en ningún lado

— Daniel f.

Respuestas:

Después de depurar esto, encontré la solución.

La causa raíz de este problema reside en el hecho de que en Ubuntu 16.04 y posteriores, las actualizaciones desatendidas usan systemd, no cron, para programar las actualizaciones con un gran retraso aleatorio:

/lib/systemd/system/apt-daily.timer está configurado con

OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h

Esto significa que se ejecutará dos veces al día, a las 6:00 y 18:00, con un retraso aleatorio de hasta 12 horas. Como esto no siempre es aceptable para entornos de producción, tuve que anular esta configuración.

Para mantener intactos los archivos de configuración del paquete, definí mi anulación en /etc/systemd/system/apt-daily.timer.d/override.conf( Actualización : lea la edición al final de esta respuesta para obtener más información sobre el nombre de archivo y la ubicación, ya que parece estar ligeramente sujeto a cambios).

Ahí puse

[Timer]
OnCalendar=
OnCalendar=06:00
RandomizedDelaySec=1h

tener actualizaciones desatendidas ejecutadas a las 6:00 más un retraso aleatorio de hasta una hora.

Luego simplemente reinicié el temporizador con systemctl restart apt-daily.timer(eventualmente necesito volver a cargar el demonio).

¡Las actualizaciones desatendidas ahora se ejecutan en tiempos predecibles nuevamente!

Editar : Parece que para Ubuntu 18.04 las cosas cambiaron un poco. La anulación ahora debe almacenarse /etc/systemd/system/apt-daily-upgrade.timer.d/override.confy tener este aspecto:

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=1h

@PerlDuck ha mencionado una forma de crear un archivo de anulación con el nombre y la ubicación correctos en un comentario a continuación. En lugar de crear un archivo manualmente, considere ejecutarsudo systemctl edit apt-daily.timer

— daniel f.
fuente

¿Por qué primero borras OnCalendar?

— jarno

Porque de lo contrario, solo AGREGARÍA un nuevo temporizador a las 6 a.m., dejando también el existente. Como quiero que las actualizaciones desatendidas se ejecuten SOLAMENTE a las 6, primero necesito borrar el cronograma.

— daniel f.

Agregué "OnBootSec = 5min" para habilitar la ejecución después del arranque también, pero no funcionó. (también se agregó OnUnitActiveSec = 12h para que no se ejecute con demasiada frecuencia.)

— jarno

systemd, o más bien, la mentalidad systemd, ataca de nuevo. Puede que tenga que repensar la actualización a Xenial Xerus en producción después de que esta gema me mordió.

— Joe

@daniel f. Tengo un archivo apt-daily.timer en / lib / systemd / system / así como uno en /etc/systemd/system/timers.target.wants/ Sin embargo, no tengo ninguno en / etc / systemd / system / a ti mismo como a ti ¿Sabría si debería crear el directorio apt-daily.timer.d y override.conf en / lib / systemd / system? Todos los consejos agradecidos con THX.

— Purvez

La documentación oficial de Debian en https://wiki.debian.org/UnattendedUpgrades actualmente tiene un error que engaña a mucha gente. Afirma que puede anular el tiempo de actualización creando un archivo llamado

/etc/systemd/system/apt-daily-upgrade.d/override.conf

Sin embargo, la ruta correcta es

/etc/systemd/system/apt-daily-upgrade.timer.d/override.conf

— Rolf Wojtech
fuente

Buen hallazgo. En mi humilde opinión, lo más seguro es usar sudo systemctl edit apt-daily.timer. Esto abrirá un editor con el archivo desplegable correcto.

— PerlDuck

Gracias PerlDuck, edité la página de Debian Wiki con su sugerencia

— Rolf Wojtech

Votó esta respuesta por ser útil, ¡y por actualizar la página wiki de Debian!

— Anthony Geoghegan

Probé la solución de Daniel pero la actualización todavía se ejecutó en los momentos equivocados. Resultó que se necesitan dos reemplazos del sistema:

Utilizado para descargas

/lib/systemd/system/apt-daily.timer - anular con /etc/systemd/system/apt-daily.timer.d/override.conf

Utilizado para actualizar

/lib/systemd/system/apt-daily-upgrade.timer - anular con /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf

— Niels Rask
fuente

¿En qué versión estás? ¿Entonces tuvo que anular ambos temporizadores mencionados al mismo tiempo?

— daniel f.

Ubuntu 16.04.4 x64

— Niels Rask