"sudo: unable to resolve host": fix /etc/hosts after a hostname change
Fix "sudo: unable to resolve host … Name or service not known" on Ubuntu and Debian: add the hostname to /etc/hosts, and keep cloud-init from undoing it.
by OhSudo ··
Every sudo command now starts with a complaint:
$ sudo whoamisudo: unable to resolve host ohsudo: Name or service not knownrootThe command still runs — but sometimes only after a pause of several seconds, and the message appears every single time. sudo looks up the machine’s own name (for host-specific rules in sudoers), and the system can’t find it.
On Debian and Ubuntu, a machine finds its own name through /etc/hosts, in a line that maps it to 127.0.1.1. If that line is missing or has an old name, the lookup fails. The usual cause: the hostname was changed (hostnamectl set-hostname, a cloned VM, a renamed cloud server), and /etc/hosts wasn’t updated.
- sudolooks up the hostnamereads
- /etc/hostsno line for the current name(breaks here)not found(fails)
- Warning, then the commandsometimes after a pause
TL;DR
1. Compare the hostname with /etc/hosts
ohsudo
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts::1 ip6-localhost ip6-loopbackUbuntu’s default /etc/hosts has a second line, 127.0.1.1 <hostname>. Here it’s missing. If it’s there but shows an old name, that’s the same problem.
getent hosts ohsudo asks the system the same question sudo asks: no output means the name doesn’t resolve.
2. Add the line
(This sudo still prints the warning once — it’s fixed right after.) If the line exists with an old name, edit it instead of adding a second one:
sudoedit /etc/hostsIf the server has a fully qualified name, put it first: 127.0.1.1 web01.example.com web01. Check:
3. The change disappears after a reboot (cloud servers)
On cloud images, cloud-init may rewrite /etc/hosts at every boot from a template. If /etc/cloud/cloud.cfg (or a file in /etc/cloud/cloud.cfg.d/) has manage_etc_hosts: true, your edit is lost. Either:
- edit the template instead:
/etc/cloud/templates/hosts.debian.tmpl, or - set the hostname through cloud-init, so the template uses the new name, or
- set
manage_etc_hosts: falseand manage the file yourself.
The comment at the top of /etc/hosts usually says when cloud-init owns it.
4. Why RHEL doesn’t show this
On RHEL, Rocky and AlmaLinux, /etc/nsswitch.conf includes myhostname in the hosts: line — a systemd module that always resolves the machine’s own name, whatever /etc/hosts says. So sudo never complains there. Ubuntu doesn’t use it by default, which is why the message is so common on Debian-family systems.
Shell, we have a problem!
Similar, but different: sudo: unable to resolve host …: Temporary failure in name resolution — same fix, but the system also tried DNS and DNS isn’t working; see Temporary failure in name resolution. guest is not in the sudoers file — the user has no sudo rights at all: add them to the sudo group (wheel on RHEL) from another admin account. If sudo refuses you instead, see not in the sudoers file.
The same missing name makes Apache print a warning at startup: see Apache AH00558.
$ ./practice.sh
Practice this in the terminal
Open the Terminal Playground with this article’s scenario loaded. It is safe and runs in your browser.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.