Ubuntu 16.04: les mises à niveau sans assistance s'exécutent à des moments aléatoires


15

J'ai configuré des mises à niveau sans assistance pour installer des packages de sécurité et avertir par courrier électronique quand il le fait.

J'ai remarqué que l'installation se produit à des moments très aléatoires. Je sais que les dernières versions ont ajouté un délai aléatoire allant jusqu'à 30 minutes à partir du temps d'exécution cron.daily.

Cependant, les retards que je vis sont bien plus importants que cela. Je vois des mises à jour sans surveillance s'exécuter à 9h, 15h, 12h ... Les journaux montrent la même chose, donc ce n'est pas seulement la livraison des e-mails qui prend plus de temps.

La tâche de mise à niveau sans assistance est la première dans cron.daily, ce qui signifie qu'il n'y a pas de tâche précédente avec des temps d'exécution énormes.

Quelqu'un a vécu une chose similaire?


Le comportement aléatoire est délibéré - pour lisser la demande au lieu de millions de systèmes martelant quelques miroirs aux mêmes heures chaque jour. Les utilisateurs de bureau ordinaires ne devraient pas du tout remarquer le comportement. Certains utilisateurs d'entreprise souhaitent modifier le comportement en quelque chose d'un peu plus prévisible et sont certainement les bienvenus.
user535733

Oui, la raison de ce choix est claire. C'est juste que ce comportement est inacceptable pour les systèmes de production. Au moment où j'ai posé cette question, ce comportement (et le correctif) n'était documenté nulle part
Daniel F.

Réponses:


20

Après avoir débogué cela, j'ai trouvé la solution.

La cause première de ce problème réside dans le fait que sous Ubuntu 16.04 et plus récent, les mises à niveau sans assistance utilisent systemd - pas cron - pour planifier les mises à jour avec un énorme retard aléatoire:

/lib/systemd/system/apt-daily.timer est configuré avec

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

Cela signifie qu'il fonctionnera deux fois par jour, à 6h00 et 18h00, avec un retard aléatoire pouvant aller jusqu'à 12 heures. Comme ce n'est pas toujours acceptable pour les environnements de production, j'ai dû remplacer ces paramètres.

Afin de garder les fichiers de configuration du package intacts, j'ai défini mon remplacement dans /etc/systemd/system/apt-daily.timer.d/override.conf( Mise à jour : veuillez lire la modification au bas de cette réponse pour plus d'informations sur le nom et l'emplacement du fichier, car il semble être légèrement sujet à changement).

Là je mets

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

pour que les mises à niveau sans assistance s'exécutent à 6h00, plus un délai aléatoire pouvant aller jusqu'à une heure.

Ensuite, j'ai simplement redémarré le minuteur avec systemctl restart apt-daily.timer(éventuellement besoin de recharger le démon).

Les mises à jour sans assistance s'exécutent à nouveau à des moments prévisibles!

Edit : Il semblerait que pour Ubuntu 18.04, les choses aient un peu changé. Le remplacement doit maintenant être stocké dans /etc/systemd/system/apt-daily-upgrade.timer.d/override.confet ressembler à ceci:

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

@PerlDuck a mentionné un moyen de créer un fichier de remplacement avec le bon nom et l'emplacement dans un commentaire ci-dessous. Au lieu de créer manuellement un fichier, pensez à exécutersudo systemctl edit apt-daily.timer


1
Pourquoi effacez-vous OnCalendar en premier?
jarno

2
Parce qu'autrement, il ne ferait qu'AJOUTER un nouveau temporisateur à 6h du matin, laissant également celui existant. Étant donné que je souhaite que les mises à niveau sans assistance fonctionnent UNIQUEMENT à 6 heures, je dois d'abord effacer le calendrier.
daniel f.

J'ai ajouté "OnBootSec = 5min" pour permettre également l'exécution après le démarrage, mais cela n'a pas fonctionné. (également ajouté OnUnitActiveSec = 12h pour qu'il ne soit pas exécuté trop fréquemment.)
jarno

systemd, ou plutôt, l'état d'esprit systemd, frappe à nouveau. Je devrai peut-être repenser la mise à niveau vers Xenial Xerus en production après que ce joyau m'a mordu.
Joe

2
@daniel f. J'ai un fichier apt-daily.timer dans / lib / systemd / system / ainsi qu'un dans /etc/systemd/system/timers.target.wants/ Cependant je n'en ai pas dans / etc / systemd / system / lui-même comme vous. Savez-vous si je devrais plutôt créer le répertoire apt-daily.timer.d et le override.conf sous / lib / systemd / system? Tous les conseils sont reconnaissants envers thx.
Purvez

6

La documentation officielle de Debian sur https://wiki.debian.org/UnattendedUpgrades contient actuellement une erreur qui trompe beaucoup de gens. Il prétend que vous pouvez remplacer le temps de mise à niveau en créant un fichier appelé

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

Cependant, le chemin correct est

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

2
Belle découverte. À mon humble avis, la chose la plus sûre est d'utiliser sudo systemctl edit apt-daily.timer. Cela ouvrira un éditeur avec le fichier de dépôt correct.
PerlDuck

2
Merci PerlDuck, j'ai édité la page Wiki Debian avec votre suggestion
Rolf Wojtech

A voté cette réponse pour son utilité - et pour la mise à jour de la page wiki Debian!
Anthony Geoghegan

5

J'ai essayé la solution de Daniel, mais la mise à niveau s'est toujours déroulée aux mauvais moments. Il s'est avéré que deux substitutions systemd sont nécessaires:

Utilisé pour les téléchargements

/lib/systemd/system/apt-daily.timer - remplacer par /etc/systemd/system/apt-daily.timer.d/override.conf

Utilisé pour la mise à niveau

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


1
Sur quelle version êtes-vous? Vous avez donc dû remplacer les deux minuteries mentionnées en même temps?
daniel f.

Ubuntu 16.04.4 x64
Niels Rask
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.