L'image de la machine virtuelle du serveur Ubuntu 16.04 démarre apparemment le "apt-daily.service" toutes les 12 heures environ; Ce service effectue diverses tâches liées à APT, telles que l'actualisation de la liste des packages disponibles, l'exécution de mises à niveau sans assistance si nécessaire, etc.
Lorsque vous démarrez à partir d'une "capture instantanée" de machine virtuelle, le service est immédiatement déclenché , car (je présume), systemd réalise rapidement que la minuterie aurait dû sonner depuis longtemps.
Cependant, un APT en cours d'exécution empêche d'autres apt
processus de s'exécuter car il est verrouillé /var/lib/dpkg
. Le message d'erreur indiquant ceci ressemble à ceci:
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Je dois désactiver cette tâche APT automatisée jusqu'à ce qu'Ansible ait terminé la configuration de la machine (ce qui implique généralement l'installation de packages). voir https://github.com/gc3-uzh-ch/elasticluster/issues/304 pour plus d'informations et le contexte.
J'ai essayé diverses options pour désactiver la fonctionnalité "Mises à niveau sans surveillance" via un script "Données utilisateur" cloud-init
, mais toutes ont échoué jusqu'à présent.
1. Désactiver la tâche systemd
La tâche systemd apt-daily.service
est déclenchée par apt-daily.timer
. J'ai essayé de désactiver l'un ou l'autre, ou les deux, avec divers cobinations des commandes suivantes; cependant, il apt-daily.service
est démarré quelques instants après que la VM soit prête à accepter les connexions SSH:
#!/bin/bash
systemctl stop apt-daily.timer
systemctl disable apt-daily.timer
systemctl mask apt-daily.service
systemctl daemon-reload
2. Désactiver l'option de configuration APT::Periodic::Enable
Le script /usr/lib/apt/apt.systemd.daily
lit quelques variables de configuration APT; le paramètre APT::Periodic::Enable
désactive complètement la fonctionnalité (lignes 331 à 337). J'ai essayé de le désactiver avec le script suivant:
#!/bin/bash
# cannot use /etc/apt/apt.conf.d/10periodic as suggested in
# /usr/lib/apt/apt.systemd.daily, as Ubuntu distributes the
# unattended upgrades stuff with priority 20 and 50 ...
# so override everything with a 99xxx file
cat > /etc/apt/apt.conf.d/99elasticluster <<__EOF
APT::Periodic::Enable "0";
// undo what's in 20auto-upgrade
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";
__EOF
Cependant, malgré APT::Periodic::Enable
sa valeur 0
depuis la ligne de commande (voir ci-dessous), le unattended-upgrades
programme est toujours exécuté ...
ubuntu@test:~$ apt-config shell AutoAptEnable APT::Periodic::Enable
AutoAptEnable='0'
3. Supprimer /usr/lib/apt/apt.systemd.daily
complètement
Le cloud-init
script suivant supprime complètement le script de mises à niveau sans assistance ::
#!/bin/bash
mv /usr/lib/apt/apt.systemd.daily /usr/lib/apt/apt.systemd.daily.DISABLED
Malgré tout, la tâche est exécutée et je peux la voir dans la table de processus! bien que le fichier n'existe pas s'il est interrogé à partir de la ligne de commande ::
ubuntu@test:~$ ls /usr/lib/apt/apt.systemd.daily
ls: cannot access '/usr/lib/apt/apt.systemd.daily': No such file or directory
Il semble que le cloud-init
script (avec la ligne de commande SSH) et le processus racine de systemd s'exécutent dans des systèmes de fichiers et des espaces de processus distincts ...
Des questions
Y a-t-il quelque chose d'évident qui me manque? Ou y a-t-il une magie de l'espace de noms en cours dont je ne suis pas au courant?
Plus important encore: comment puis-je désactiver le apt-daily.service
via un
cloud-init
script?
--now
drapeau dans la systemctl disable
commande pour que le changement prenne effet immédiatement. C'était mon problème.
disable --now
est équivalent à stop
suivi de disable
.