Jak wyłączyć `apt-daily.service` na obrazie VM maszyny w chmurze Ubuntu?

Obraz maszyny Wirtualnej serwera Ubuntu 16.04 najwidoczniej uruchamia „apt-daily.service” co około 12 godzin; ta usługa wykonuje różne zadania związane z APT, takie jak odświeżanie listy dostępnych pakietów, wykonywanie nienadzorowanych aktualizacji w razie potrzeby itp.

Rozpoczynając od „migawki” maszyny wirtualnej, usługa jest uruchamiana natychmiast , ponieważ (jak sądzę) systemd szybko zdaje sobie sprawę, że licznik powinien był zadziałać dawno temu.

Jednak działający APT uniemożliwia uruchomienie innych aptprocesów, ponieważ blokuje /var/lib/dpkg. Komunikat o błędzie wskazujący to wygląda następująco:

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?

Muszę wyłączyć to automatyczne zadanie APT, dopóki Ansible nie zakończy konfiguracji komputera (co zwykle wiąże się z instalacją pakietów); zobacz https://github.com/gc3-uzh-ch/elasticluster/issues/304, aby uzyskać więcej informacji i kontekst.

Próbowałem różnych opcji, aby wyłączyć funkcję „nienadzorowanej aktualizacji” za pomocą skryptu „danych użytkownika” cloud-init, ale jak dotąd wszystkie zawiodły.

1. Wyłącz zadanie systemowe

Zadanie systemd apt-daily.servicejest uruchamiane przez apt-daily.timer. Próbowałem wyłączyć jedno lub drugie, lub oba, przy pomocy różnych poleceń następujących poleceń; nadal apt-daily.servicejest uruchamiany chwilę po tym, jak maszyna wirtualna będzie gotowa do przyjmowania połączeń SSH:

    #!/bin/bash

    systemctl stop apt-daily.timer
    systemctl disable apt-daily.timer
    systemctl mask apt-daily.service
    systemctl daemon-reload

2. Wyłącz opcję konfiguracji APT::Periodic::Enable

Skrypt /usr/lib/apt/apt.systemd.dailyodczytuje kilka zmiennych konfiguracyjnych APT; ustawienie APT::Periodic::Enablecałkowicie wyłącza funkcjonalność (wiersze 331--337). Próbowałem wyłączyć go za pomocą następującego skryptu:

    #!/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

Jednak pomimo APT::Periodic::Enablewartości 0z wiersza poleceń (patrz poniżej) unattended-upgradesprogram jest nadal uruchomiony ...

    ubuntu@test:~$ apt-config shell AutoAptEnable APT::Periodic::Enable
    AutoAptEnable='0'

3. Usuń /usr/lib/apt/apt.systemd.dailycałkowicie

Poniższy cloud-initskrypt całkowicie usuwa skrypt nienadzorowanej aktualizacji:

    #!/bin/bash

    mv /usr/lib/apt/apt.systemd.daily /usr/lib/apt/apt.systemd.daily.DISABLED

Mimo to zadanie działa i widzę je w tabeli procesów! chociaż plik nie istnieje, jeśli sondowany z linii poleceń:

ubuntu@test:~$ ls /usr/lib/apt/apt.systemd.daily
ls: cannot access '/usr/lib/apt/apt.systemd.daily': No such file or directory

Wygląda na to, że cloud-initskrypt (wraz z wierszem poleceń SSH) i proces systemowy wykonywany są w osobnych systemach plików i przestrzeniach procesów ...

pytania

Czy brakuje mi czegoś oczywistego? A może dzieje się jakaś magia przestrzeni nazw, o której nie wiem?

Co najważniejsze: w jaki sposób można wyłączyć apt-daily.serviceza pomocą cloud-initskryptu?

Tak, coś oczywistego mi brakowało.

Systemd polega na równoczesnym rozpoczęciem usługi, więc cloud-initskrypt jest uruchamiany jednocześnieapt-daily.service jest uruchomiony. Do czasu, cloud-initaby wykonać ładunek określony przez użytkownika, apt-get updatejuż działa. Tak więc próby 2. i 3. nie powiodły się nie z powodu pewnej magii przestrzeni nazw, ale dlatego, że zbyt późno zmieniły system, aby można apt.systemd.dailybyło zauważyć zmiany.

Oznacza to również, że w zasadzie nie ma możliwości uniemożliwienia apt.systemd.daily uruchomienia - można go zabić dopiero po uruchomieniu.

Ten skrypt „danych użytkownika” podąża tą drogą:

#!/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

Nadal istnieje okno czasowe, w którym logowanie SSH jest możliwe, ale jeszcze apt-get się nie uruchomi, ale nie wyobrażam sobie innego rozwiązania, które może działać na standardowym obrazie w chmurze Ubuntu 16.04.

Uwaga: Niestety część poniższego rozwiązania nie działa na systemach Ubuntu 16.04 (takich jak pytający), ponieważ sugerowane systemd-runwywołanie działa tylko na Ubuntu 18.04 i nowszych ( szczegółowe informacje można znaleźć w komentarzach ). Pozostawię tutaj odpowiedź, ponieważ to pytanie jest wciąż popularnym hitem, niezależnie od używanej wersji Ubuntu ...

W systemie Ubuntu 18.04 (i nowszych wersjach) mogą występować maksymalnie dwie usługi związane z aktualizacją / aktualizacją w czasie rozruchu. Pierwszy apt-daily.serviceodświeża listę pakietów. Może jednak istnieć sekunda, apt-daily-upgrade.servicektóra faktycznie instaluje pakiety o krytycznym znaczeniu dla bezpieczeństwa. Odpowiedź na „Zakończ i wyłączyć / usunąć nienadzorowanej uaktualnienie przed zwrotów komenda” pytanie daje doskonały przykład tego, jak czekać na oba te skończyć (skopiowany tutaj dla wygody):

systemd-run --property="After=apt-daily.service apt-daily-upgrade.service" --wait /bin/true

(zwróć uwagę, że należy to uruchomić jako root). Jeśli próbujesz wyłączyć te usługi przy przyszłych rozruchach, musisz zamaskować OBIE usługi:

systemctl mask apt-daily.service apt-daily-upgrade.service

Alternatywnie możesz systemctl disablezarówno usługi ORAZ powiązane z nimi liczniki (tj. apt-daily.timerI apt-daily-upgrade.timer).

Zwróć uwagę, że techniki maskowania / wyłączania zawarte w tej odpowiedzi zapobiegają tylko aktualizacji / aktualizacji w przyszłych uruchomieniach - nie zatrzymają ich, jeśli są już uruchomione w bieżącym rozruchu.

Możesz to wyłączyć za pomocą modułu inicjującego chmurę „bootcmd”. Działa to przed uruchomieniem sieci, co jest wymagane, zanim apt update może uzyskać szansę na uruchomienie.

#cloud-config
bootcmd:
    - echo 'APT::Periodic::Enable "0";' > /etc/apt/apt.conf.d/10cloudinit-disable
    - apt-get -y purge update-notifier-common ubuntu-release-upgrader-core landscape-common unattended-upgrades
    - echo "Removed APT and Ubuntu 18.04 garbage early" | systemd-cat

Gdy wpiszesz ssh do instancji, powinieneś także poczekać na zakończenie końcowych faz inicjowania chmury, ponieważ przenosi on odpowiednie źródła / listy.

# Wait for cloud-init to finish moving apt sources.list around... 
# a good source of random failures
# Note this is NOT a replacement for also disabling apt updates via bootcmd
while [ ! -f /var/lib/cloud/instance/boot-finished ]; do
    echo 'Waiting for cloud-init to finish...'
    sleep 3
done

Jest to również pomocne, aby zobaczyć, jak wcześnie uruchamia się bootcmd:

# Show microseconds in systemd journal
journalctl -r -o short-precise

Możesz to sprawdzić w następujący sposób:

apt-config dump | grep Periodic

# Verify nothing was updated until we run apt update ourselves.
cd /var/lib/apt/lists
sudo du -sh .   # small size
ls -ltr         # old timestamps

Nie byłoby łatwiej maskować urządzenia

systemctl mask apt-daily.service

?

To czeka 1 sekundę w pętli whil i sprawdza, czy zamek jest zwolniony.

while : ; do
                sleep 1
                echo $( ps aux | grep -c lock_is_held ) processes are using apt.
                ps aux | grep -i apt
                [[ $( ps aux | grep -c lock_is_held ) > 2 ]] || break
        done
        echo Apt released