How to Change Hostname in Linux: hostnamectl, /etc/hostname, and Cloud

Q: How do I see all the hostnames?

`hostnamectl` shows static, transient, and pretty. `hostname -f` shows the FQDN. `hostname -A` shows all aliases. `hostname -i` shows the IP. The team that uses these for debugging has the right tools.

Changing the hostname in Linux is sudo hostnamectl set-hostname newname.example.com on modern systemd-based distros. The change is immediate for new processes and survives reboots. Cloud instances (AWS, GCP, Azure) sometimes revert the hostname on reboot because cloud-init resets it - the fix is preserve_hostname: true in /etc/cloud/cloud.cfg or the cloud provider’s hostname config.

The hostnamectl command
Verify the change
Update /etc/hosts
Cloud-init and cloud instances
The legacy hostname file approach
FAQ

The hostnamectl command

On Ubuntu 16.04+, Debian 9+, RHEL 7+, CentOS 7+, Fedora, and any systemd-based distro:

sudo hostnamectl set-hostname newname.example.com

That command updates three places: /etc/hostname (the persistent file), /proc/sys/kernel/hostname (the kernel value, immediate), and the systemd-hostnamed service. The new hostname is visible immediately in new shells and survives reboot.

Verify the change

Check the current hostname:

hostname
# or
hostnamectl

hostnamectl shows the static (persistent), transient (kernel), and pretty (display) hostnames. The team that sees the new value in Static hostname: has the right setup.

Update /etc/hosts

The hostname also needs to resolve to 127.0.0.1 in /etc/hosts:

127.0.0.1   localhost
127.0.0.1   newname.example.com newname

Without this entry, many tools (especially sudo and postfix) complain about being unable to resolve the hostname. The team that forgets /etc/hosts updates gets sudo: unable to resolve host warnings after the change.

Cloud-init and cloud instances

On cloud VMs (AWS EC2, GCP Compute Engine, Azure VMs, DigitalOcean droplets), cloud-init may reset the hostname on reboot. The fix is /etc/cloud/cloud.cfg:

preserve_hostname: true

That tells cloud-init to leave the hostname alone. The team that has set the hostname manually but sees it revert after a reboot needs this setting.

Alternative: re-run cloud-init’s hostname module on boot by setting the hostname in cloud-init’s set_hostname directive instead of preserve_hostname. The right answer depends on whether the team wants cloud-init to manage the hostname (it can pull from the cloud metadata) or wants to set it manually and have it stick (preserve_hostname).

The legacy hostname file approach

On older non-systemd distros, edit /etc/hostname directly:

echo "newname" | sudo tee /etc/hostname
sudo /etc/init.d/hostname.sh start

Or on the older RHEL family (RHEL 6 and earlier):

echo "HOSTNAME=newname" | sudo tee /etc/sysconfig/network
sudo /etc/init.d/network restart

The team that is on a modern distro should use hostnamectl - the legacy approach is harder to get right and does not survive reboots without extra config.

FAQ

Do I need to reboot after changing the hostname?

No, but new shell sessions will see the new hostname. Existing shells still show the old one. The team that wants the change visible everywhere reboots or starts a new shell.

What is a valid hostname?

Letters, digits, and hyphens, between 1 and 63 characters per label, multiple labels separated by dots. web1.example.com is valid. -web1 is not. web_1 is technically valid but uncommon. The team that picks hostnames that match RFC 1123 avoids DNS validation issues.

Will changing the hostname affect running services?

Most services do not care about the hostname and continue running. The exceptions are services that bind to a specific hostname (Postfix, some web servers) - those need a reload to pick up the new name.

How do I see all the hostnames?

hostnamectl shows static, transient, and pretty. hostname -f shows the FQDN. hostname -A shows all aliases. hostname -i shows the IP. The team that uses these for debugging has the right tools.

Can I change the hostname on a running production server?

Yes. The change is non-disruptive for most workloads. The team that does this on a server with strict monitoring should expect the hostname change to show up in alerts - update the monitoring config first or accept the alert churn.

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: