How to Resolve "sudo: unable to resolve host" Error in Ubuntu

Every sudo command prints a hostname resolution warning before actually running, even though your network connection works fine otherwise. This is sudo trying to resolve your machine's own hostname — not a remote server — and failing because /etc/hosts doesn't have a matching entry.

The Problem

Any use of sudo shows the warning first, then still runs the command anyway:

$ sudo apt update
sudo: unable to resolve host myserver01: Name or service not known
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
...

Checking the current hostname confirms it's set to something not reflected in /etc/hosts:

$ hostname
myserver01

Why It Happens

When sudo runs, it tries to resolve your machine's own hostname as part of its normal startup routine (this is used for logging and PAM checks). If the hostname reported by hostname doesn't have a corresponding entry in /etc/hosts, that lookup fails with a "Name or service not known" error, even though the command itself still executes fine afterward. This mismatch usually happens because:

• The hostname was changed (manually, or by a cloud provider's instance metadata) after /etc/hosts was last configured, so the two are now out of sync.
• A server was cloned or provisioned from an image/snapshot, and the cloning process changed the hostname without updating /etc/hosts to match.
• DHCP or a cloud-init script sets a hostname dynamically on every boot, and it doesn't always match the static entries in /etc/hosts.
• The system's DNS resolver has no way to resolve the hostname externally either, and /etc/hosts was supposed to be the fallback but was never updated.

The Fix

Check the exact hostname your system currently reports:

hostname

myserver01

Open /etc/hosts and look for a line mapping 127.0.0.1 or 127.0.1.1 to a hostname:

cat /etc/hosts

127.0.0.1   localhost
127.0.1.1   old-hostname

If the hostname listed doesn't match what hostname reports, edit the file to fix it:

sudo nano /etc/hosts

127.0.0.1   localhost
127.0.1.1   myserver01

Save the file and confirm the warning is gone:

sudo apt update

If there's no 127.0.1.1 line at all, add one matching your current hostname exactly:

echo "127.0.1.1   $(hostname)" | sudo tee -a /etc/hosts

If you'd rather fix it by changing the hostname back instead of editing /etc/hosts, that works too, as long as it stays consistent going forward:

sudo hostnamectl set-hostname old-hostname

Still Not Working?

If you're on a cloud VM (AWS, GCP, DigitalOcean) and the hostname keeps reverting after every reboot despite fixing /etc/hosts, cloud-init is likely resetting it on boot based on instance metadata. Check whether cloud-init is managing your hostname and either disable that specific behavior or make your /etc/hosts fix persistent across reboots via cloud-init's own config:

sudo nano /etc/cloud/cloud.cfg

# add or confirm this line to stop cloud-init from managing /etc/hosts
manage_etc_hosts: false

After changing this, reboot and verify both the hostname and /etc/hosts stay consistent, and re-run sudo apt update to confirm the warning no longer appears.

It's also worth knowing this warning is entirely cosmetic in most cases — it doesn't prevent the actual sudo command from running, since the hostname lookup is only used for PAM logging and auditing purposes, not for authorizing the command itself. If you're in a hurry and just need commands to run without the noise, fixing /etc/hosts as described above is still the right long-term fix, but understanding that your scripts and automation aren't actually broken by this warning can save some unnecessary debugging time under pressure.

If you manage several servers and want to catch this proactively rather than reactively, add a quick consistency check to your provisioning or configuration management setup that verifies the hostname and /etc/hosts stay in sync after any hostname change:

#!/bin/bash
current_hostname=$(hostname)
if ! grep -q "127.0.1.1.*$current_hostname" /etc/hosts; then
    echo "WARNING: /etc/hosts is out of sync with hostname: $current_hostname"
    exit 1
fi

Running this as a periodic check or as part of a deployment pipeline catches the mismatch immediately after a hostname change, rather than waiting for someone to notice the warning during routine sudo usage days later.