¿Cómo deshabilitar `apt-daily.service` en la nube de Ubuntu VM imagen?

Nota: Desafortunadamente, parte de la solución a continuación no funciona en los sistemas Ubuntu 16.04 (como la del interrogador) porque la sugerencia systemd-run invocación solo funciona en Ubuntu 18.04 y superior (vea comentarios para más detalles ). Dejaré la respuesta aquí porque esta pregunta sigue siendo un éxito popular, independientemente de la versión de Ubuntu que esté utilizando ...

En Ubuntu 18.04 (y superior) puede haber hasta dos servicios involucrados en el tiempo de arranque para actualizar/actualizar. El primero apt-daily.service actualiza la lista de paquetes. Sin embargo, puede haber un segundo apt-daily-upgrade.service que realmente instala paquetes críticos de seguridad. Un respuesta a la pregunta "Finalizar y deshabilitar/eliminar la actualización desatendida antes de que el comando regrese" ofrece un excelente ejemplo de cómo esperar a que ambos terminen (copiado aquí por conveniencia):

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

(tenga en cuenta que esto debe ejecutarse como root). Si está intentando deshabilitar estos servicios en futuras botas, deberá enmascarar AMBOS servicios:

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

Alternativamente, puedes systemctl disable ambos servicios Y sus temporizadores asociados (es decir, apt-daily.timer y apt-daily-upgrade.timer).

Tenga en cuenta que las técnicas de enmascaramiento/desactivación en esta respuesta solo impiden la actualización/actualización en futuras botas; no las detendrán si ya se están ejecutando en el arranque actual.

Puede deshabilitar esto a través del módulo "bootcmd" cloud-init. Esto se ejecuta antes de que aparezca la red, lo cual es necesario antes de que apt update pueda tener la oportunidad de ejecutarse.

#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

Una vez que ingrese a la instancia, también debe esperar a que finalicen las fases finales de cloud-init, ya que mueve las fuentes/listas aptas.

# 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

Esto también es útil para ver qué tan temprano se ejecuta bootcmd:

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

Puede verificar que esto funcionó de la siguiente manera:

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

¿No sería más fácil enmascarar la unidad?

systemctl mask apt-daily.service

?

Basado en la solución de Anon, creé este script, que después de ejecutarlo y luego reiniciarlo, resuelve el problema para mí:

#!/bin/sh

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

Si el propósito es aprovisionar la máquina sin incurrir en un error de bloqueo, la solución más simple y estable es ejecutar el comando remoto del aprovisionador (o los comandos relacionados con apt) mientras se bloquea el archivo de bloqueo apt-daily. Sin servicio de enmascaramiento/desactivación/espera, etc.etc.

En el servidor Ubuntu, los programas de actualización de paquetes (apt-daily, desatendido-actualizaciones, cloud-init), pasan por apt-daily, por lo que la solución puede centrarse en él.

Apt-daily usa los bloqueos flock(2), que, a diferencia de dpkg/apt (que usan fnctl), se pueden administrar mediante una herramienta de línea de comandos, con la conveniencia de que admite esperar en el bloqueo.

Por lo tanto, si uno, por ejemplo, usa Chef, es tan simple como correr, en los nodos:

$ Sudo flock /var/lib/apt/daily_lock chef-client

y:

• cualquier chef-cliente tomará la cerradura primero, y cualquier servicio basado en apt-daily esperará;
• o cualquier servicio basado en apt-daily lo bloqueará primero, luego chef-clien esperará y finalmente se ejecutará una vez que apt-daily se complete.

Si no se invoca el aprovisionador en los nodos, es posible modificar la configuración del aprovisionador (por ejemplo, Ansible Playbook) para ejecutar:

$ Sudo flock /var/lib/apt/daily_lock apt update
$ Sudo flock /var/lib/apt/daily_lock apt upgrade

(o cualquier variación, como sh -c '...' y así)

Fuente: https://saveriomiroddi.github.io/Handling-the-apt-lock-on-ubuntu-server-installations .

Esto espera 1 segundo en un bucle while y comprueba si se libera el bloqueo.

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

Este cloud-init funciona.

#cloud-config
apt:
  conf: |
    APT {
      Periodic {
        Update-Package-Lists "0";
      };
    };
    Unattended-Upgrade {
      Package-Blacklist {
        "*";
      };
    };
runcmd:
  - [ systemctl, stop, apt-daily.timer, apt-daily-upgrade.timer ]
  - [ systemctl, disable, apt-daily.timer, apt-daily-upgrade.timer ]