Diagnosing and Fixing Ubuntu Unattended‑Upgrades Failures

The Problem: Missing Security Patches

When the unattended-upgrades service fails, Ubuntu servers stop receiving critical security patches automatically. This often goes unnoticed until a vulnerability scan reveals outdated packages or a manual update shows a backlog of security updates that should have been applied weeks prior.

Diagnostic Mapping

Use this table to match the error strings found in the logs to the most likely root cause.

Log Error String	Likely Cause	Primary Diagnostic Tool
\"Failed to fetch\"	Network or DNS failure	curl / ping
\"Could not get lock /var/lib/dpkg/lock-frontend\"	Process contention (APT lock)	lsof / ps
\"No packages upgraded\" (when updates exist)	Stale or corrupted APT lists	apt-get update
Service not starting/running	Configuration disablement	cat /etc/apt/apt.conf.d/20auto-updates

Step‑by‑Step Troubleshooting

Follow these checks in order. Do not skip to the fixes until the specific failure point is identified.

1. Verify Network Reachability

The service cannot apply updates if it cannot reach the Ubuntu archive mirrors. Run this command from the terminal to check the connection to the primary archive:

curl -I http://archive.ubuntu.com/ubuntu/

Expected Result: An HTTP/1.1 200 OK response. If you receive a timeout or a DNS resolution error, the issue is at the network layer, not within the unattended‑upgrades service.

2. Identify Lock Contention

APT allows only one process to manage the package database at a time. If another process (like a manual apt upgrade or a third‑party software installer) is running, unattended-upgrades will fail.

Check which process is holding the lock using lsof (requires sudo):

sudo lsof /var/lib/dpkg/lock-frontend

Risk: Do not manually delete .lock files. Doing so can corrupt the dpkg database if a process is still actively writing to it.

3. Validate APT List Integrity

If the network is fine and there are no locks, the local package index may be stale or corrupted, leading the service to believe no updates are available.

Run a manual update to see if errors occur during the fetch phase:

sudo apt-get update

4. Inspect Service Configuration

Ensure the automatic update triggers are actually enabled. Check the 20auto-updates configuration file:

cat /etc/apt/apt.conf.d/20auto-updates

Verify that APT::Periodic::Update-Package-Lists and APT::Periodic::Unattended-Upgrade are both set to "1".

Targeted Fixes

Apply the fix corresponding to the finding in the previous section.

• For Network/DNS Errors: Correct the /etc/resolv.conf file or verify firewall rules allow outbound traffic on port 80 and 443 to the Ubuntu mirrors.
• For Lock Contention: Identify the conflicting process via ps aux | grep apt. If it is a hung process, terminate it gracefully using kill [PID]. Wait for the process to exit before restarting the service.
• For Corrupted Lists: Clear the local cache and force a fresh download:

  sudo apt-get clean && sudo apt-get update

• For Configuration Errors: Edit /etc/apt/apt.conf.d/20auto-updates using a text editor (e.g., nano) to set the values to "1".

Verification and Validation

Once a fix is applied, do not wait for the next scheduled run to verify the result. Use the dry‑run flag to simulate the process without altering the system state.

sudo unattended-upgrade --dry-run --debug

Success Criteria: The output should list Packages that will be upgraded without accompanying Failed to fetch or Lock error strings. If the dry run completes successfully, the service is operational.

Escalation Criteria

If the following conditions persist, the issue is likely beyond the scope of the unattended‑upgrades service and requires deeper system investigation:

• Manual execution of sudo apt-get upgrade fails with the same errors encountered by the service.
• The system reports Read‑only file system errors in dmesg or /var/log/syslog, indicating filesystem corruption.
• The dpkg database is reported as corrupted and sudo dpkg --configure -a fails to resolve the state.