Apt Periodic is disabled instead of enabling Retries

So the grammar of that sentence is awful. And an easy fix. The relevant change is actually made twice, and stored in the 10periodic and the 20retries file. I'm struggling to recall why, as it's possible one of those is supposed to be disabling something else.

That said, I vaguely running into problems where the various Debian/Ubuntu background services, and/or scheduled job timers would launch while the box was being built, and they proved exceedingly difficult to disable. The retry logic, and or background update jobs caused numerous issues, from contention for the package database lock, to altering the OS config while the apt.sh script was running. And if those jobs hit an error, they could cause further chaos. For example, if the problem was the network, the background task would 'stall' and repeatedly retry it's task before giving up. Which would either cause the commands in the apt.sh script to fail, or block waiting for the background task to finish. This was causing all sorts of issues, from timeouts, because the script exceeded the 1hr limit, to having commands return various errors that weren't handled, and couldn't be solved by a retry. The solution was to disable those tasks/timers/services, at least until the box was built. Which is why the apt-daily/snapd are stopped and not disabled. Presumably once the apt.sh script is finished the bulk of the system updates, basic packages are installed, and the system is rebooted (so that things like guest tools are compiled against the newest kernel). So it becomes less of an issue.

I'd still like to know why I created I try disabling periodic twice.

lavabit / robox

Apt Periodic is disabled instead of enabling Retries #224