The Ubuntu 16.04 server VM image apparently starts the "apt-daily.service" every 12 hours or so; this service performs various APT-related tasks like refreshing the list of available packages, performing unattended upgrades if needed, etc.
When starting from a VM "snapshot", the service is triggered immediately, as (I presume) systemd realizes quickly that the timer should have gone off long ago.
However, a running APT prevents other
apt processes from running as it holds a
/var/lib/dpkg. The error message indicating this looks like this:
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?
I need to disable this automated APT task until Ansible has completed the machine setup (which typically involves installing packages); see https://github.com/gc3-uzh-ch/elasticluster/issues/304 for more info and context.
I have tried various options to disable the "unattended upgrades" feature
through a "user data" script for
cloud-init, but all of them have failed so
1. Disable the systemd task
apt-daily.service is triggered by
apt-daily.timer. I have tried
to disable one or the other, or both, with various cobinations of the following
commands; still, the
apt-daily.service is started moments after the VM becomes
ready to accept SSH connections::
#!/bin/bash systemctl stop apt-daily.timer systemctl disable apt-daily.timer systemctl mask apt-daily.service systemctl daemon-reload
2. Disable config option
/usr/lib/apt/apt.systemd.daily reads a few APT configuration
variables; the setting
APT::Periodic::Enable disables the functionality
altogether (lines 331--337). I have tried disabling it with the following
#!/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
APT::Periodic::Enable having value
0 from the command line
(see below), the
unattended-upgrades program is still run...
ubuntu@test:~$ apt-config shell AutoAptEnable APT::Periodic::Enable AutoAptEnable='0'
cloud-init script removes the unattended upgrades script
#!/bin/bash mv /usr/lib/apt/apt.systemd.daily /usr/lib/apt/apt.systemd.daily.DISABLED
Still, the task runs and I can see it in the process table! although the file does not exist if probed from the command line::
ubuntu@test:~$ ls /usr/lib/apt/apt.systemd.daily ls: cannot access '/usr/lib/apt/apt.systemd.daily': No such file or directory
It looks as though the
cloud-init script (together with the SSH command-line)
and the root systemd process execute in separate filesystems and process
Is there something obvious I am missing? Or is there some namespace magic going on which I am not aware of?
Most importantly: how can I disable the
apt-daily.service through a