apt-get calls don't set DPkg::Lock::Timeout, fail immediately on dpkg lock contention

[colinbjohnson]

Title

apt-get calls don't set DPkg::Lock::Timeout, fail immediately on dpkg lock contention

Description

None of the script's apt-get calls set DPkg::Lock::Timeout, so any of them fail immediately if another process holds the dpkg lock (e.g. cloud-init running a concurrent apt-get on first boot):

Installing package(s): datadog-agent datadog-signing-keys
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2332 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
ERROR
Failed to install one or more packages...

Acquire::Retries, used on the install calls, only retries failed downloads, not lock acquisition. apt has a built-in flag for this: -o DPkg::Lock::Timeout=<seconds> makes apt poll for the lock instead of failing immediately.

Suggested fix

Add -o DPkg::Lock::Timeout='<n>' to every apt-get call in the script.

Potential Improvement

If/when support for earlier versions of apt is dropped, the APT_DEPS retry loop (L1533-1560) could be removed in favor of DPkg::Lock::Timeout, which is silently ignored on older apt:

$sudo_cmd apt-get update -o DPkg::Lock::Timeout="60"
$sudo_cmd DEBIAN_FRONTEND=noninteractive apt-get install -o Acquire::Retries="5" -o DPkg::Lock::Timeout="60" -y "${APT_DEPS[@]}"