Box fails to provision due to a lock file being locked

[martinandersson]

Each apt-get (also apt and aptitude?) process instance lock a lock file to make sure it never runs concurrently (because otherwise, shit happens?).

Recent Ubuntu/Debian releases have an "apt daily" timer setup which fires off on boot (I believe this comes as part of the unattended-upgrades package). This will cause the lock file to be locked and subsequent provisioning done by Vagrant that uses apt-get will fail. It has also been reported that it makes the machine startup slow.

Actually, /lib/systemd/system/apt-daily.timer is configured to fire the timer each day at a random time. But it also has Persistent=true set which makes the machine catch up a missed event immediately on boot.

Setting Persistent=false (default value) should "fix the problem". But I don't consider this an optimal solution for two reasons.

Firstly, this reduces the likelihood of the collision to happen but does not definitively get rid of the problem, the chance is still there if that random event time happened to be right at boot. Secondly, I agree with this comment that the update process shouldn't run at a random time at all. It should be deterministic (at least to some degree) and occur some short time after boot.

Solution: Configure the apt daily timer such that it elapses 15-45 minutes after boot. It may also be delayed up to one hour at the discretion of the system (to minimize CPU wake-ups). Repeat every day the machine stays awake.

Some good-to-have links:

• https://github.com/geerlingguy/packer-ubuntu-1604/issues/3
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844453
• https://www.freedesktop.org/software/systemd/man/systemd.timer.html
• https://www.freedesktop.org/software/systemd/man/systemd.service.html
• https://askubuntu.com/a/659268
• https://askubuntu.com/a/831206
• https://ubuntu-mate.community/t/shorten-boot-time-apt-daily-service/
• https://lists.freedesktop.org/archives/systemd-devel/2017-April/038772.html

[martinandersson]

It has been noted that although the problem is gone most of the times, it can still happen. So apparently there are even more processes that need to be reconfigured.

I will reopen this issue and change the wording for release v10.0.1 in the changelog from "fixed" to "improved". But for the moment, I regard this issue as an infrequent upstream one not worthy of my time.