apt / unattended-upgrades stalls shutdown

13

Une fois unattended-upgradesinstallé, 9 arrêts / redémarrages sur 10 se bloquent pendant le "démarrage de l'arrêt des mises à niveau sans assistance". Ce blocage bloque le processus d'arrêt pendant 5 à 10 minutes.

Si je désactive les mises à niveau sans assistance via le /etc/apt/apt.conf.d/20auto-upgrades and/or 50unattended-upgrades, les problèmes se produisent.

Si j'arrête le service avant l'arrêt / le redémarrage ( sudo service unattended-upgrades stop), le problème persiste.

Si je supprime le package ( sudo apt remove unattended-upgrades), le problème ne se produit plus.

Cela se produit sur une version fraîchement installée de Ubuntu Server 16.04.1(toutes deux unattended-upgradesinstallées via une interface graphique d'installation ou une installation manuelle de mises à niveau sans assistance)

Les deux Kern.log & syslogne montrent pas le processus d'arrêt (je crois parce que les systèmes de fichiers ont déjà été démontés)

Quelqu'un d'autre a-t-il vu ou résolu ce problème? Devenir fou en essayant de le dépanner.

16.04 apt shutdown unattended-upgrades garullon245136
la source
Impossible de reproduire dans une machine virtuelle de test 16.04.1. L'arrêt n'est pas retardé ici.
user535733
Pourrait-il être basé sur le matériel? Je ne sais pas exactement ce qui se passe unattended-upgradespendant l'arrêt.
garullon245136
Je me demande pourquoi uu est toujours en cours d'exécution au moment de l'arrêt: uu n'est pas un démon; c'est simplement un script qui s'exécute brièvement une fois par jour et se termine ensuite.
user535733
Il semble que le processus d'arrêt essaie de s'exécuter uu pendant l'étape où tous les systèmes de fichiers sont démontés. Cela ne semble pas être contrôlé par les liens /etc/rc6.d/ ou /etc/rc0.d/ comme J'ai supprimé tous les liens et le processus s'exécute toujours pendant l'arrêt.
garullon245136
1
Regardez dans /etc/apt/apt/conf.d/50unattended-upgrades pour l'option 'run uu at shutdown' (autour de la ligne 25). Assurez-vous qu'il est «faux» ou commenté.
user535733

Réponses:

14

Regarder autour de soi pour se rapprocher de la cause profonde

Le problème semble être le script exécuté à l'arrêt.

J'ai identifié le fichier correspondant avec:

find /etc/systemd -name *unattended*

ce qui m'a donné le script systemd connexe:

/etc/systemd/system/shutdown.target.wants/unattended-upgrades.service

qui m'a ensuite indiqué le script exécuté à l'arrêt:

/usr/share/unattended-upgrades/unattended-upgrade-shutdown

Enquêter plus profondément pour trouver la cause profonde

dans ce script, il y a une section à la ligne 120 liée à la section dans /etc/apt/apt.conf.d/50unattended-upgrades -> Unattended-Upgrade :: InstallOnShutdown

Ligne 120 de / usr / share / unattended-upgrades / unattended-upgrade-shutdown:

if apt_pkg.config.find_b("Unattended-Upgrade::InstallOnShutdown", False):

Le problème: il attend le mot-clé "False" alors que dans la conf apt, nous devons ajouter "false" (comparaison exacte des chaînes)!

Solution

J'ai pu résoudre / contourner l'arrêt au point mort de 3 manières différentes:

Solution de contournement A

  • écrire "False" au lieu de "false" dans /etc/apt/apt.conf.d/50unattended-upgrades

Ce paramètre est sûr pour la mise à niveau jusqu'à ce qu'un véritable correctif soit fourni car le fichier que nous modifions ici n'est pas remplacé par une mise à jour des mises à niveau sans assistance. Problème: Lorsque la cause première est corrigée, cela entraînera à nouveau un arrêt de décrochage, je suggère donc de combiner cela avec la solution de contournement B.

OU: solution de contournement B

  • réduisez le temps d'attente dans /etc/systemd/system/shutdown.target.wants/unattended-upgrades.service de la valeur par défaut à 15 secondes:

vim /etc/systemd/system/shutdown.target.wants/unattended-upgrades.service

[Un service]
Type = oneshot
ExecStart = / usr / share / unattended-upgrades / unattended-upgrade-shutdown
TimeoutStartSec = 15

Ce paramètre n'est PAS sécurisé pour la mise à niveau car le fichier que nous modifions ici peut être remplacé par une mise à jour des mises à niveau sans assistance. En plus de cela, il est vraiment loin de réparer quelque chose, mais cela garantira que votre système n'attendra pas plusieurs minutes lors de l'arrêt. Gardez à l'esprit qu'après une mise à niveau des mises à niveau sans assistance, vous devrez peut-être le redéfinir!

OU: Correction C (à signaler en amont)

  • fix / usr / share / unattended-upgrades / unattended-upgrades-shutdown pour attendre "false" au lieu de "False"

patcher / usr / share / unattended-upgrades / unattended-upgrade-shutdown:

--- / tmp / unattended-upgrade-shutdown 2017-02-03 14: 53: 03.238103238 +0100
+++ / tmp / unattended-upgrade-shutdown_fix 2017-02-03 14: 53: 17.685589001 +0100
@@ -117,7 +117,7 @@
     # exécuter
     p = Aucun
     apt_pkg.init_config ()
- si apt_pkg.config.find_b ("Unattended-Upgrade :: InstallOnShutdown", False):
+ si apt_pkg.config.find_b ("Unattended-Upgrade :: InstallOnShutdown", false):
         env = copy.copy (os.environ)
         env ["UNATTENDED_UPGRADES_FORCE_INSTALL_ON_SHUTDOWN"] = "1"
         logging.debug ("démarrage des mises à niveau sans assistance en mode d'arrêt")

Conclusion

tbh seul le dernier est un vrai correctif. les deux autres options ne sont que des solutions de contournement jusqu'à ce que le vrai correctif soit implémenté.

Cela doit être fait en amont et comme cela affecte à la fois Debian (testé sur Debian Stretch) et Ubuntu (testé sur Ubuntu 16.04.1) pour les deux distributions.

J'ai ouvert un rapport de bogue ici: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611

steadfasterX
la source
2
apt_pkg.config.find_b () renvoie un booléen et non une chaîne. "find_b (key [, default = False]) → bool Renvoie la valeur booléenne stockée à key, ou la valeur donnée par l'objet bool par défaut si l'option demandée n'est pas définie." apt.alioth.debian.org/python-apt-doc/library/… Ce n'est donc pas un bogue dans la mise à niveau sans assistance-arrêt car la vérification de False est correcte.
Brian Murray
Comme le verra tous ceux qui suivent le lien de rapport de bogue Launchpad ci-dessus, ce problème n'était pas en fait dû à une comparaison de chaînes échouée, mais était plutôt dû à un bogue de séquençage systemd qui aurait été corrigé .
sampablokuper
1

Comme solution de contournement, j'utilise ce script pour le corriger:

#!/usr/bin/env bash

sed -i '/if apt_pkg.config.find_b/s/False/false/' /usr/share/unattended-upgrades/unattended-upgrade-shutdown

exit

Espérons que ce sera bientôt en amont.

caracal
la source