sudo hostnamectl set-hostname newname sets the hostname. But it does not update /etc/hosts, and that is where sudo breaks. The team that runs the two commands together has the right setup. The team that runs only the first breaks sudo and a few other system services with confusing ‘unable to resolve host’ errors.
Table of contents
- The two places the hostname lives
- The three types of hostname systemd tracks
- Updating /etc/hosts without breaking sudo
- cloud-init on cloud servers
- Verifying the change worked
- FQDN vs hostname vs domain
- FAQ
The two places the hostname lives
On a modern systemd-managed Linux system, the hostname lives in two places. The first is the kernel hostname, which hostname and uname -n read. The second is the static hostname file at /etc/hostname. The hostnamectl set-hostname command updates both, but it does not update /etc/hosts. The /etc/hosts file is the local name-to-IP map that predates DNS, and many system services (sudo, apt, postfix, gnome-shell) consult it for the local hostname before they hit DNS. If the hostname in /etc/hostname is newname but /etc/hosts still maps 127.0.1.1 to oldname, sudo logs a warning and continues, and a few services fail outright.
The right procedure is the two-command sequence:
sudo hostnamectl set-hostname newname
sudo nano /etc/hostsIn /etc/hosts, change the line that maps 127.0.1.1 to the old hostname so it maps to the new one. On a typical Ubuntu or Debian system, the file looks like:
127.0.0.1 localhost
127.0.1.1 oldnameChange the second line to:
127.0.1.1 newnameDo not touch the 127.0.0.1 localhost line. The 127.0.1.1 address is a Debian convention for the local hostname that is separate from 127.0.0.1 (which is reserved for localhost itself). The two are different addresses and they are both correct in the file.
The three types of hostname systemd tracks
Systemd’s hostnamectl tracks three different hostnames. The first is static, which is what the kernel reads at boot. The second is pretty, which is the human-readable form. The third is transient, which is set by DHCP or mDNS and changes when the network changes.
The right workflow is to set the static hostname with hostnamectl set-hostname newname. The static hostname is the one the kernel reads, the one /etc/hostname contains, and the one that survives a reboot. The pretty hostname is for display only (e.g., My Workstation). The transient hostname is automatic; do not set it manually unless you know exactly why you need to.
To see the current state:
hostnamectl statusThe output includes all three, the chassis type (laptop, desktop, server, vm, container), the machine ID, and the boot ID. The right answer for verifying a hostname change is to look at the Static hostname line.
Updating /etc/hosts without breaking sudo
The sudo breakage is the most common symptom. The error is:
sudo: unable to resolve host newname: Name or service not knownThis means sudo tried to look up the local hostname before running, and the lookup failed. The cause is that /etc/hosts still maps the local hostname to the old name. The fix is the edit above.
If you see this error, the system is not broken. Sudo is still working — the error is in the lookup, not the execution. The command runs anyway. But the fix is still to update /etc/hosts because the warning will appear on every sudo invocation, and other tools (apt, postfix) will fail with similar errors.
A related issue is that the host key fingerprint in ~/.ssh/known_hosts (or the system one) will change. If you SSH back to the box from another host, you will see a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED and a Man-in-the-middle alert. The right answer is to remove the old entry:
ssh-keygen -R newnameThen reconnect and accept the new fingerprint.
cloud-init on cloud servers
On AWS, GCP, Azure, and most other cloud providers, the Ubuntu image ships with cloud-init, which sets the hostname on every boot from the cloud provider’s metadata service. If you set the hostname manually on a cloud server, the next reboot will revert it.
The right answer is to either set the hostname through the cloud provider’s API (which updates the metadata that cloud-init reads) or to disable cloud-init’s hostname management. The way to disable it:
sudo nano /etc/cloud/cloud.cfgFind the preserve_hostname line and set it to true:
preserve_hostname: trueAfter that, the hostname is preserved across reboots. The same setting exists for most cloud images, not just Ubuntu. On a server you manage through the cloud provider’s API, the right answer is to set the hostname through the API and let cloud-init handle it. The right answer for a server where you want manual control is to disable cloud-init’s hostname management.
Verifying the change worked
The right verification is the three-command sequence:
hostname
hostname -f
uname -nhostname returns the short hostname. hostname -f returns the FQDN, which requires a working /etc/hosts and a working resolv.conf to resolve. If hostname -f errors with hostname: Name or service not known, the /etc/hosts file is wrong. uname -n is the same as hostname and is included for completeness.
A more thorough verification is getent hosts newname. This queries the name service switch (NSS) the way most applications do — first /etc/hosts, then DNS. If the result is 127.0.1.1, the system is correctly resolving the hostname to the loopback. If the result is empty or wrong, the /etc/hosts or DNS configuration is wrong.
FQDN vs hostname vs domain
The full picture has three pieces. The short hostname is newname. The domain is example.com. The FQDN is newname.example.com. hostnamectl set-hostname newname.example.com sets the FQDN, but the short hostname is also newname.example.com until you set it explicitly.
The right pattern is to set the FQDN with hostnamectl set-hostname, and let the short hostname fall out of it. Most distros and most services will use the FQDN when one is set. The wrong pattern is to set the short hostname with hostnamectl set-hostname and then have a service that needs the FQDN break because it appends the domain from somewhere and gets the wrong result.
If you do not have a domain, the right answer is to use a single label (e.g., newname). The system will treat it as both the short name and the FQDN. The downside is that you cannot have a proper FQDN without a domain. For a home lab, that is fine. For a production box, the right answer is to set the domain through DHCP or /etc/resolv.conf and let the FQDN resolve through the proper DNS path.
FAQ
Do I need to restart the system after changing the hostname?
No. hostnamectl set-hostname updates the running kernel. The change is immediate. The only thing that needs a restart is a service that read the hostname at boot and caches it. The list of services that cache the hostname is short — typically just Postfix and a few logging services. The right answer is to restart those services after the change, not the whole box.
My hostname keeps changing back on reboot. What is wrong?
Almost always cloud-init, on a cloud server. The fix is to set preserve_hostname: true in /etc/cloud/cloud.cfg. On a non-cloud box, the cause is usually a DHCP server that returns a hostname option. The fix is to either set the DHCP server to not return a hostname option, or to set the static hostname to be more authoritative than the DHCP one.
Can I have a hostname with spaces or special characters?
No. The hostname must match the RFC 952 / RFC 1123 rules: letters, digits, and hyphens, up to 63 characters per label, total FQDN up to 253 characters. Underscores are technically allowed in some contexts but break DNS resolution. The right answer is to use only letters, digits, and hyphens, with no spaces or special characters.
What is the difference between hostname and /etc/hostname?
The hostname command reads from a kernel-level system call (the uname syscall). /etc/hostname is the file that the kernel reads at boot to populate the kernel hostname. On a running system, the two should match. The kernel can change its hostname (via hostname newname or via hostnamectl set-hostname), but /etc/hostname is only updated by hostnamectl (or by hand). On a system that has the kernel hostname set but /etc/hostname empty, the kernel hostname is ephemeral and will revert to whatever /etc/hostname says after a reboot.
How do I see the FQDN in the terminal prompt?
Most distros already show it in the default PS1. If not, edit ~/.bashrc and set:
PS1='\u@\h:\w\$ '\h is the short hostname, \H is the FQDN. The difference matters when the box is in a domain. The right answer for production boxes is \H so you can tell at a glance which server you are on.
What about Windows?
Windows has its own hostname management through the System control panel, the hostname command (a different one than Linux’s), and PowerShell’s Rename-Computer. The right answer on Windows is the same as on Linux: change the hostname through the system API, then update any local files that reference it. The /etc/hosts equivalent on Windows is C:\Windows\System32\drivers\etc\hosts.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: