Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apt lock file due to unattended-upgrades causes issues with initial provisioning #3

Closed
geerlingguy opened this issue May 12, 2016 · 6 comments

Comments

@geerlingguy
Copy link
Owner

I could reproduce this issue one time last night, though I've seen a couple other reports of it happening. Basically, Ubuntu 16.04 defaults to running uattended-upgrades automatically (out of the box). What happens is that the first time a box is brought up, unattended-upgrades locks apt (see /var/lib/dpkg/lock), and then provisioning scripts error out if they install anything via apt.

The solution I think I'll go with (since I recommend people use the geerlingguy.security) to manage automatic upgrades themselves) is to disable the feature when building via kickstart (as suggested by @gretel):

d-i pkgsel/update-policy select unattended-upgradesd-i pkgsel/update-policy select unattended-upgrades

See related: hashicorp/vagrant#7155 (comment)

@geerlingguy
Copy link
Owner Author

Testing a new base box build with the changed unattended-upgrades setting.

@topikito
Copy link

Hi @geerlingguy - Whats the approach then? :)

@geerlingguy
Copy link
Owner Author

@topikito - I'm uploading the new box version now. I'll be pushing a commit to fix this issue in a couple minutes, once I finish validating the build.

@topikito
Copy link

Thanks for taking the time to consider my issue @geerlingguy

@agilethomas
Copy link

In case anyone else comes across this thread, I found a way to solve this problem without disabling unattended-upgrades. What I found was that the apt-daily service was triggering the unattended-upgrades immediately on bootup, and that caused the dpkg lock to occur. The systemd setting that causes it to do that is a timer (which now replaces cron and anacron from what I gather) which is in this file:

/lib/systemd/system/apt-daily.timer

...
[Timer]
OnCalendar=*-*-* 6,18:00
Persistent=true
...

and the direct cause is the "Persistent" directive, which tells systemd to run the command immediately on bootup if the job was missed while the system was down. Of course, with vagrant, it will always miss this run as long as the image is older than a day. I solved this on my own Xenial vagrant box by adding this file:

/etc/systemd/system/apt-daily.timer.d/apt-daily.timer.conf

consisting entirely of these 2 lines (which override the setting in the other file):

[Timer]
Persistent=false

I suspect there may be a better way (I'm new to vagrant) but I can't see how the default ubuntu timer setting is a good idea for vagrant boxes, since they are started and stopped on a more frequent basis than a regular computer. Anytime a vagrant box is brought up, it will run the unattended-upgrades if it missed running it, which will break any apt-get provisioning that gets done. So setting Persistent=false will avoid that.

@geerlingguy
Copy link
Owner Author

@agilethomas - Awesome! I still kind of like leaving it off by default and having the user enable if desired, mostly because my Vagrant boxes are only intended for local dev, and I always add the caveat that if you consider doing something like vagrant share, using public networking, or using the box elsewhere... it's up to you to provide security, and just having automatic updates wouldn't be enough :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants