As opposed to editing /etc/hostname, or wherever is relevant?
There must be a good reason (I hope) - in general I much prefer the "old" way, where everything was a text file. I'm not trying to be contentious - I'd really like to know, and to decide for myself if it's a good reason. Thanks.
hostnamectl is part of systemd, and provides a proper API for dealing with setting a server's hostnames in a standardized way.
$ rpm -qf $(type -P hostnamectl)
systemd-219-57.el7.x86_64
Previously each distro that did not use systemd, had their own methods for doing this which made for a lot of unnecessary complexity.
DESCRIPTION hostnamectl may be used to query and change the system hostname and related settings.This tool distinguishes three different hostnames: the high-level "pretty" hostname which might include all kinds of special characters (e.g. "Lennart's Laptop"), the static hostname which is used to initialize the kernel hostname at boot (e.g. "lennarts-laptop"), and the transient hostname which is a default received from network configuration. If a static hostname is set, and is valid (something other than localhost), then the transient hostname is not used.
Note that the pretty hostname has little restrictions on the characters used, while the static and transient hostnames are limited to the usually accepted characters of Internet domain names.
The static hostname is stored in /etc/hostname, see hostname(5) for more information. The pretty hostname, chassis type, and icon name are stored in /etc/machine-info, see machine-info(5).
Use systemd-firstboot(1) to initialize the system host name for mounted (but not booted) system images.
hostnamectl also pulls a lot of disparate data together into a single location to boot:
$ hostnamectl
Static hostname: centos7
Icon name: computer-vm
Chassis: vm
Machine ID: 1ec1e304541e429e8876ba9b8942a14a
Boot ID: 37c39a452464482da8d261f0ee46dfa5
Virtualization: kvm
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-693.21.1.el7.x86_64
Architecture: x86-64
The info here is coming from /etc/*release, uname -a, etc. including the hostname of the server.
Incidentally, everything is still in files, hostnamectl is merely simplifying how we have to interact with these files or know their every location.
As proof of this you can use strace -s 2000 hostnamectl and see what files it's pulling from:
$ strace -s 2000 hostnamectl |& grep ^open | tail -5
open("/lib64/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/proc/self/stat", O_RDONLY|O_CLOEXEC) = 3
open("/etc/machine-id", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 4
open("/proc/sys/kernel/random/boot_id", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 4
To the astute observer, you should notice in the above strace that not all files are present. hostnamectl is actually interacting with a service, systemd-hostnamectl.service which in fact does the "interacting" with most of the files that most admins would be familiar with, such as /etc/hostname.
Therefore when you run hostnamectl you're getting details from the service. This is a ondemand service, so you won't see if running all the time. Only when hostnamectl runs. You can see it if you run a watch command, and then start running hostnamectl multiple times:
$ watch "ps -eaf|grep [h]ostname"
root 3162 1 0 10:35 ? 00:00:00 /usr/lib/systemd/systemd-hostnamed
The source for it is here: https://github.com/systemd/systemd/blob/master/src/hostname/hostnamed.c and if you look through it, you'll see the references to /etc/hostname etc.
-e open,openat?
– ydaetskcoR
Aug 01 '18 at 08:57
strace 8-). All though to be honest I would've still needed the grep to get the output the way I wanted to show it, b/c the strace would've still shown the output of the hostnamectl cmd, so my way was shorter.
– slm
Aug 01 '18 at 09:00
rpm -qf $(type -P hostnamectl) I've got to remember that one!
– Mark Borgerding
Oct 07 '19 at 17:34
hostnamectl can't edit /etc/hosts, why does it allow setting the hostname as anything else without even warning the admin about that?
– Det
Oct 29 '22 at 09:55
It is still a text file, you can still edit it, and there will not be a problem.
The text file has been standardized to /etc/hostname.
According to the maintainer, the services systemd-hostname, systemd-timedated etc were very much designed for existing GUI(s) like GNOME. systemd-hostnamed lets a GUI request hostname changes without running as root (depending on the polkit policy). Dbus also provides a method to subscribe changes, which is suited to GUI needs. Maybe used by a total of one app in these cases :). I dunno, maybe clocks use systemd-timedated to listen for timezone reconfiguration?
Think of hostnamectl as a stub to exercise the GUI backend, which might or might not also be a useful CLI utility. systemd-hostnamed is specifically not intended to add whole features which are not exercised by GUI code.
The systemd-hostnamed service is not intended to abstract over differences between distributions. Upstream systemd standardized on a single configuration file, /etc/hostname, where there were previously different config files on e.g. Debian v.s. Redhat based distributions.
This assumes hostnamectl is talking to the standard implementation of systemd-hostnamed. But AFAIK there's no current distribution that patches the filename used.
I want to point out that loading /etc/hostname at boot time is performed early on by systemd PID 1. It doesn't depend on running systemd-hostnamed.
I imagine you might notice one harmless difference, if you have a system settings GUI open and showing the hostname at the same time. If you edit /etc/hostname and then use hostname --file /etc/hostname to apply the change to the running system, the GUI display might not instantly update. systemd-hostnamed provides dbus notifications on changes to all the versions of the hostname it maintains, so the GUI might not bother to listen for the system hostname notifications provided on modern Linux kernels.
(Traditionally, it's a bad idea to do the changing the hostname at runtime thing. It may cause problems with software such as X. I'm confident this issue is not addressed by systemd. Perhaps it has been addressed by distributions which use systemd).
