You type sudo apt update on your VPS and, before anything runs, you get sudo: unable to resolve host myserver: Name or service not known. The command usually still works, which makes it easy to ignore. Don't. It's a sign your server's hostname and its hosts file have drifted apart, and that can slow every sudo call and trip up mail, cron and monitoring tools. Here's how to fix it properly.

Symptom: what you'll see

The message varies slightly by distro, but it always follows the same shape:

sudo: unable to resolve host web01: Name or service not known
sudo: unable to resolve host web01: Temporary failure in name resolution

Common side effects:

  • Every sudo command pauses for 5–10 seconds before running.
  • Postfix, Exim or cron jobs log odd hostname warnings.
  • Some services (MySQL, Java apps, monitoring agents) hang at start-up while they try to look up their own name.

Cause: the hostname isn't in /etc/hosts

When you run sudo, it looks up the machine's own hostname so it can log and match sudoers rules. That lookup goes through /etc/hosts first, then DNS. If your hostname is not listed in /etc/hosts and no DNS record exists for it, the lookup fails.

It typically happens in these situations:

  • You changed the hostname with hostnamectl set-hostname but never updated /etc/hosts.
  • A cloud image was cloned or rebuilt and kept the old hosts entry.
  • You edited /etc/hostname by hand and forgot the second file.
  • The DNS resolver itself is down, so the fallback lookup also fails (this gives the Temporary failure variant).

Fix: step by step

1. Check the current hostname

hostname
hostnamectl status
cat /etc/hostname

All three should agree. Note the exact name, for example web01 or web01.example.com.

2. Look at /etc/hosts

cat /etc/hosts

A healthy file on Ubuntu or Debian looks like this:

127.0.0.1   localhost
127.0.1.1   web01.example.com web01
203.0.113.10 web01.example.com web01

::1         localhost ip6-localhost ip6-loopback

If your hostname isn't on any line, that's your culprit.

3. Add the missing entry

If sudo itself is complaining, it will still run, just slowly. Edit the file:

sudo nano /etc/hosts

Add a line mapping the name to the loopback address, or better, to the server's public IP:

127.0.1.1   web01

Use your real hostname, not the placeholder. If you use a fully qualified name, put it first, then the short name after it.

4. Test immediately

sudo true
getent hosts $(hostname)

The first command should return instantly with no warning. The second should print an IP and your name. If both work, you're done.

5. If you're on RHEL, AlmaLinux or Rocky

The same rule applies. The default line is usually:

127.0.0.1   localhost localhost.localdomain localhost4
::1         localhost localhost.localdomain localhost6

Append your hostname to the first line or add a new line below it. If you run cpanel" class="auto-link">wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel/WHM, set the hostname from WHM (Networking Setup → Change Hostname) so cPanel updates its own config at the same time.

6. Don't be locked out while you fix it

If sudo is genuinely broken, not just warning, switch to root with su - or use the SkyServer VPS console from your control panel, then edit the file as root.

When the DNS resolver is the real problem

If the error says Temporary failure in name resolution and your hosts entry is already correct, the problem is elsewhere. Check:

cat /etc/resolv.conf
resolvectl status
ping -c2 1.1.1.1
ping -c2 google.com

If the IP ping works but the domain ping fails, your resolver is misconfigured. We've covered that in detail in our guide on fixing "Temporary failure in name resolution" on a VPS.

Quick reference table

SituationLikely causeFix
Warning appears right after renaming server/etc/hosts has the old nameUpdate the line to the new name
Warning on a fresh cloned VPSImage kept the template hostnameSet hostname, then fix /etc/hosts
Sudo is slow but worksFailed lookup timing outAdd hostname to /etc/hosts
Hosts entry fine, still failsBroken DNS resolverFix /etc/resolv.conf or systemd-resolved

Prevention

  • Change both places. Any time you run hostnamectl set-hostname, open /etc/hosts right after.
  • Use a proper FQDN. A name like web01.yourdomain.com with a matching A record avoids guesswork for mail servers.
  • Keep cloud-init in check. On cloud images, set preserve_hostname: true in /etc/cloud/cloud.cfg if cloud-init keeps overwriting your changes.
  • Test after reboots. Run sudo true once after any rename so you catch it early.
Rule of thumb: if getent hosts $(hostname) returns nothing, something on your server will eventually complain about it.

Frequently Asked Questions

Is "unable to resolve host" a security problem?

No. It's a configuration mismatch, not an attack. It's still worth fixing because it slows sudo and can confuse services that depend on the hostname.

Why does the command still run despite the error?

Sudo treats the failed lookup as a warning. It falls back after a timeout and carries on, which is why you see a delay rather than a hard failure.

Should I use 127.0.0.1 or 127.0.1.1 for the hostname?

Debian and Ubuntu traditionally use 127.0.1.1 for the machine name. If the server has a static public IP, mapping the FQDN to that IP is also fine, and often better for mail servers.

Do I need to reboot after editing /etc/hosts?

No. The file is read on every lookup, so the change takes effect immediately. Only a hostname change itself may need a re-login for your shell prompt to update.

I run cPanel/WHM. Is the fix different?

The hosts file fix is the same, but change the hostname through WHM so cPanel's own configuration and SSL stay consistent with it.