Ubuntu - Comment désactiver `apt-daily.service` sur l'image Ubuntu Cloud Vm?

L'image de 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, comme rafraîchir
la liste des packages disponibles, effectuer des mises à niveau sans surveillance si nécessaire, etc.

Lors du démarrage à partir d'un "instantané" de VM, le service est déclenché immédiatement , car (je
présume) systemd se rend compte rapidement que le minuteur aurait dû sonner depuis longtemps.

Cependant, un APT en cours d'exécution empêche les autres apt processus de s'exécuter car il détient un
verrou sur /var/lib/dpkg . Le message d'erreur indiquant cela 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" pour cloud-init , mais tous ont échoué jusqu'à
jusqu'à présent.

1. Désactiver la tâche systemd

tâche systemd apt-daily.service est déclenché par apt-daily.timer . J'ai essayé
de désactiver l'une ou l'autre, ou les deux, avec diverses combinaisons des commandes
suivantes ; encore, le apt-daily.service est lancé quelques instants après que la VM est
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

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 ayant pour valeur depuis la ligne de commande
(voir ci-dessous), le champ unattended-upgrades le programme est toujours exécuté…

    [email protected]:~$ apt-config shell AutoAptEnable APT::Periodic::Enable
    AutoAptEnable='0'

3. Supprimer /usr/lib/apt/apt.systemd.daily tout à fait

Le cloud-init suivant le script 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

Pourtant, la tâche s'exécute et je peux la voir dans la table des processus ! bien que le fichier
n'existe pas s'il est testé depuis la ligne de commande : :

[email protected]:~$ 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 le script (avec la ligne de commande SSH)
et le processus root systemd s'exécutent dans des systèmes de fichiers et des espaces
de processus distincts…

Questions

Y a-t-il quelque chose d'évident qui me manque? Ou y a-t-il une magie d'espace de noms
dont je ne suis pas au courant ?

Connexe :Différence entre [] et () dans l'expression régulière de base ?

Plus important encore :comment désactiver le apt-daily.service via un
cloud-init script ?

Réponse acceptée :

Oui, il y avait quelque chose d'évident qui me manquait.

Systemd concerne le démarrage simultané des services, donc le cloud-init le script est
exécuté en même temps le apt-daily.service est déclenché. Au moment où cloud-init obtient d'exécuter la charge utile spécifiée par l'utilisateur, apt-get update est
déjà en cours d'exécution. Ainsi, les tentatives 2. et 3. ont échoué non pas à cause de la magie de l'espace de noms
, mais parce qu'elles ont modifié le système trop tard pour apt.systemd.daily pour
reprendre les modifications.

Cela signifie également qu'il n'y a pratiquement aucun moyen d'empêcher apt.systemd.daily de courir - on ne peut le tuer qu'après qu'il ait commencé.

Ce script "données utilisateur" emprunte cette route : :

#!/bin/bash

systemctl stop apt-daily.service
systemctl kill --kill-who=all apt-daily.service

# wait until `apt-get updated` has been killed
while ! (systemctl list-units --all apt-daily.service | egrep -q '(dead|failed)')
do
  sleep 1;
done

# now proceed with own APT tasks
apt install -y python

Il y a encore une fenêtre de temps pendant laquelle les connexions SSH sont encore possibles apt-get ne fonctionnera pas, mais je ne peux pas imaginer une autre solution qui puisse fonctionner sur l'image cloud stock
Ubuntu 16.04.