Como desabilitar o 'apt-daily.service' na imagem da nuvem do Ubuntu na VM?

Question

A imagem da VM do servidor Ubuntu 16.04 aparentemente inicia o "apt-daily.service" a cada 12 horas ou mais; este serviço executa várias tarefas relacionadas ao APT como atualizar a lista de pacotes disponíveis, executando atualizações autônomas, se necessário, etc.

Ao iniciar a partir de uma "captura instantânea" da VM, o serviço é acionado imediatamente , como (I presumir) systemd percebe rapidamente que o temporizador deveria ter disparado há muito tempo.

No entanto, um APT em execução impede que outros processos apt sejam executados, pois ele contém bloquear em /var/lib/dpkg . A mensagem de erro indicando isso é assim:

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?

Eu preciso desabilitar essa tarefa automatizada do APT até que o Ansible concluiu a configuração da máquina (que normalmente envolve a instalação de pacotes); veja link para mais informações e contexto.

Eu tentei várias opções para desativar o recurso "upgrades autônomos" através de um script de "dados do usuário" para cloud-init , mas todos falharam agora.

1. Desativar a tarefa do systemd

tarefa systemd apt-daily.service é acionada por apt-daily.timer . eu tentei para desativar um ou o outro, ou ambos, com vários cobinations dos seguintes comandos; ainda assim, o apt-daily.service é iniciado momentos após a VM se tornar pronto para aceitar conexões SSH ::

    #!/bin/bash

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

2. Desativar opção de configuração APT::Periodic::Enable

Script /usr/lib/apt/apt.systemd.daily lê algumas configurações do APT variáveis; a configuração APT::Periodic::Enable desativa a funcionalidade no total (linhas 331--337). Eu tentei desativá-lo com o seguinte script ::

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

No entanto, apesar de APT::Periodic::Enable ter valor 0 na linha de comando (veja abaixo), o programa unattended-upgrades ainda é executado ...

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

3. Remova /usr/lib/apt/apt.systemd.daily completamente

O script cloud-init a seguir remove o script de atualizações autônomas ao todo ::

    #!/bin/bash

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

Ainda assim, a tarefa é executada e eu posso vê-la na tabela de processos! embora o arquivo não existe se sondado a partir da linha de comando ::

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

Parece que o script cloud-init (junto com a linha de comando SSH) e o processo systemd raiz é executado em sistemas de arquivos e processos separados espaços ...

Perguntas

Existe algo óbvio que estou perdendo? Ou há alguma mágica de namespace indo de que não conheço?

Mais importante: como desabilitar o apt-daily.service por meio de cloud-init script?

    

Answer 1

Sim, havia algo óbvio que estava faltando.

O Systemd tem tudo a ver com o início simultâneo de serviços, portanto, o script cloud-init é executar ao mesmo tempo o apt-daily.service é acionado. Quando chegar a hora cloud-init consegue executar a carga útil especificada pelo usuário, apt-get update é já correndo. Então as tentativas 2. e 3. falharam não por causa de algum namespace mágica, mas porque eles alteraram o sistema muito tarde para apt.systemd.daily escolha as mudanças.

Isso também significa que basicamente não há como impedir apt.systemd.daily da execução - só é possível matá-lo depois de iniciado.

Este script de "dados do usuário" segue este caminho:

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

Ainda existe uma janela de tempo durante a qual os logins de SSH são possíveis ainda apt-get não vai rodar, mas não consigo imaginar outra solução que funcione no estoque Imagem da nuvem do Ubuntu 16.04.

    

Answer 2

Nota: Infelizmente, parte da solução abaixo não funciona nos sistemas Ubuntu 16.04 (como o do questionador) porque a invocação systemd-run sugerida funciona apenas no Ubuntu 18.04 e acima (veja o comentários para detalhes ). Vou deixar a resposta aqui porque esta questão ainda é um sucesso popular, independentemente da versão do Ubuntu que você está usando ...

No Ubuntu 18.04 (e acima), pode haver até dois serviços envolvidos no tempo de inicialização para atualizar / atualizar. O primeiro apt-daily.service atualiza a lista de pacotes. No entanto, pode haver um segundo apt-daily-upgrade.service que, na verdade, instala pacotes críticos de segurança. Uma resposta para a mensagem "Finalizar e desabilitar / remover atualizações automáticas antes do retorno do comando" fornece um excelente exemplo de como aguarde até que ambos terminem (copiados aqui por conveniência):

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

(note que isso deve ser executado como root). Se você estiver tentando desativar esses serviços em inicializações futuras, será necessário mascarar ambos os serviços:

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

Como alternativa, você pode systemctl disable dos dois serviços E seus timers associados (por exemplo, apt-daily.timer e apt-daily-upgrade.timer ).

Observe que as técnicas de mascaramento / desativação nesta resposta apenas impedem a atualização / atualização em inicializações futuras - elas não as impedirão se já estiverem em execução na inicialização atual.

    

Answer 3

Você pode desabilitar isso através do módulo cloud-init "bootcmd". Isso é executado antes que a rede seja ativada, o que é necessário antes de o apt update ter a chance de ser executado.

#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

Uma vez que você tenha ssh na instância, você também deve esperar que as fases finais do cloud-init terminem, já que ele move apt sources / lists por aí.

# 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

Isso também é útil para ver o quão cedo o bootcmd é executado:

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

Você pode verificar se isso funcionou da seguinte maneira:

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

    

Answer 4

Não será mais fácil mascarar a unidade

systemctl mask apt-daily.service

?

    

Answer 5

Isso aguarda 1 segundo em um loop whil e verifica se o bloqueio é liberado.

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