To change the hostname in Linux without rebooting, run sudo hostnamectl set-hostname newname and update the line in /etc/hosts that maps 127.0.1.1 to the old hostname. The two-step is mandatory — the first command does not touch /etc/hosts, and a mismatch between /etc/hostname and /etc/hosts breaks sudo with a confusing warning.
Table of contents
- The two-step procedure
- What hostnamectl actually does
- The three hostname types systemd tracks
- The /etc/hosts trap explained
- Cloud-init override on cloud servers
- What if you have multiple hostnames (container, multi-NIC)?
- FAQ
The two-step procedure
The right procedure to change the hostname is the two-step. First, set the new hostname:
sudo hostnamectl set-hostname newnameSecond, update /etc/hosts:
sudo nano /etc/hostsFind the line that looks like:
127.0.1.1 oldnameChange oldname to newname. Do not change the 127.0.0.1 localhost line. The two addresses are different (127.0.0.1 is for localhost, 127.0.1.1 is for the local hostname) and both are correct in the file.
The right verification is:
hostname
hostname -fhostname returns the short hostname. hostname -f returns the FQDN, which requires the /etc/hosts change to work. If hostname -f errors, the /etc/hosts file is wrong.
What hostnamectl actually does
The hostnamectl command is part of systemd. It updates three things: the kernel hostname (read by uname -n), the static hostname file at /etc/hostname, and the systemd-hostnamed daemon’s internal state. The right answer is that the change is immediate — no reboot, no service restart.
The wrong answer is to expect hostnamectl to update /etc/hosts. The systemd team has explicitly chosen not to do this. The reason is that /etc/hosts is a user-edited file with local conventions, and the tool cannot know the operator’s intent. The right answer is to update it by hand.
The right answer for the static hostname file is to verify it after the command:
cat /etc/hostnameThe file should contain the new hostname. If it does not, the change did not take effect. The right answer for a system that is not running systemd (e.g., Devuan, Artix) is to set the hostname with the legacy hostname command and update /etc/hostname by hand.
The three hostname types systemd tracks
Systemd tracks three types of hostname. The first is static, which is the persistent hostname stored in /etc/hostname. The second is pretty, which is the human-readable form (can include spaces and special characters). The third is transient, which is set by DHCP or mDNS and changes with the network.
The right answer for a server is to set the static hostname. The right answer for a workstation is to set both the static and the pretty hostname — the pretty one shows up in the login screen, the static one is what scripts and services read.
The right verification:
hostnamectl statusThe output shows all three hostnames, plus the chassis type (laptop, desktop, server, vm, container) and the machine ID. The right answer for a server is Chassis: server or Chassis: vm — the wrong answer is Chassis: laptop on a server, which means the install media was misconfigured.
The /etc/hosts trap explained
The /etc/hosts file is the local name-to-IP map that predates DNS. Many services consult it before hitting DNS. The services that consult /etc/hosts for the local hostname include sudo, apt, postfix, gnome-shell, and a few logging services. The right answer for a working system is that /etc/hosts resolves the local hostname to a loopback address.
The wrong answer is to leave the old hostname in /etc/hosts. The error that results is:
sudo: unable to resolve host newname: Name or service not knownThis error appears on every sudo invocation. Sudo still works — the command runs anyway. But the warning is annoying and breaks tools that depend on a clean resolve (apt, postfix).
The right answer is to also check /etc/resolv.conf if you have a domain set:
search example.comIf your hostname is newname and your domain is example.com, the FQDN is newname.example.com. The right answer is to make sure /etc/hosts resolves both the short and the FQDN, or to make sure search in /etc/resolv.conf resolves it.
Cloud-init override 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 or to disable cloud-init’s hostname management. To disable it on Ubuntu:
sudo nano /etc/cloud/cloud.cfgFind the preserve_hostname line and set it to true:
preserve_hostname: trueOn a non-cloud box, the cause of hostname resets is usually a DHCP server that returns a hostname option. The fix is to either configure the DHCP server to not return a hostname option or to set the static hostname to be more authoritative than the DHCP one.
What if you have multiple hostnames (container, multi-NIC)?
A Linux box can have multiple hostnames in different contexts. A container has its own hostname (the container’s name), which is different from the host’s hostname. A multi-NIC box might want different hostnames on different interfaces, which is not a thing Linux supports — the hostname is a kernel-level value, not per-interface.
The right answer for a container is to let the container runtime manage the hostname. Docker, Kubernetes, and systemd-nspawn all set the hostname inside the container. The right answer for a multi-NIC box is to have one hostname and use DNS to point the right services to the right IPs.
The wrong answer is to try to set the hostname per-interface — Linux does not support it. The right answer is to pick one canonical hostname and stick with it.
FAQ
Does the change survive a reboot?
Yes, if you updated /etc/hostname (which hostnamectl set-hostname does) and /etc/hosts. The change is persistent. The exception is cloud-init, which can override it on every boot. The right answer for a cloud box is to set preserve_hostname: true in /etc/cloud/cloud.cfg.
Can I have a hostname with a dot in it?
Yes, the FQDN has dots. The right answer is to set the FQDN with hostnamectl set-hostname newname.example.com. The kernel hostname is the FQDN, and the short hostname is the part before the first dot. The right answer for tools that expect a short hostname is to query hostname -s.
What is the difference between hostname and uname -n?
Nothing, on a modern system. Both query the kernel hostname. The right answer is to use either; they return the same value. The wrong answer is to think one is more authoritative than the other.
Why does the hostname not update in my terminal prompt?
The terminal prompt is set by the shell’s PS1 variable, which is read once at shell start. Changing the hostname does not update the prompt in a running shell. The right answer is to start a new shell (open a new terminal) or to source ~/.bashrc to reload the prompt.
Can I see the hostname of a remote box?
Yes, with ssh user@host hostname or nslookup <ip>. The first is the right answer for a box you can SSH to. The wrong answer is to trust DNS for a box that is in a private network — DNS may not know about it.
What is the difference between hostname and domain name?
The hostname is the name of a single machine (newname). The domain name is the network the machine belongs to (example.com). The FQDN is the combination (newname.example.com). The right answer for a Linux box is to set the FQDN with hostnamectl set-hostname newname.example.com. The right answer for a machine without a domain (a home lab box) is to set just the hostname.
My hostname contains uppercase letters. Is that OK?
Technically yes, but the wrong answer. The right answer is to use lowercase only, because the hostname is also a DNS name and DNS is case-insensitive in lookup but case-preserving in records. The right answer is to keep it lowercase to avoid confusion. The wrong answer is to mix case and rely on the system to normalize it.
How do I rename a host permanently with no reboot and no cloud-init?
On a system without systemd, the answer is sudo hostname newname and then update /etc/hostname by hand. The kernel hostname is updated immediately, the persistent file is updated for the next boot, and the change survives a reboot. The wrong answer is to use the legacy hostname command and forget to update /etc/hostname — the change will revert on reboot.
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: