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.

  • 4
    You are most definitely not alone --- Systemd introduced a lot of new interfaces and because of that it got a lot of flak from people who prefer "the old way where everything was a text file". Commented Aug 1, 2018 at 6:58
  • 1
    @FedericoPoloni Or where not everything was a text file, like DNS queries being converted into XML for no reason. Commented Aug 1, 2018 at 8:04
  • DNS-> xml . Sorry, you're going to have to come up with an example, please. IMO XML is the invention of satan, BTW. Commented Aug 1, 2018 at 15:13

2 Answers 2



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)

Previously each distro that did not use systemd, had their own methods for doing this which made for a lot of unnecessary complexity.

  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.

What about the files?

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.


  • 1
    See unix.stackexchange.com/a/454785/5132 for one example of reading the file(s) directly.
    – JdeBP
    Commented Jul 31, 2018 at 15:31
  • Is there a reason to grep the output instead of use -e open,openat?
    – ydaetskcoR
    Commented Aug 1, 2018 at 8:57
  • @ydaetskcoR - no technical reason, was being lazy and didn't look up the switches to 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
    Commented Aug 1, 2018 at 9:00
  • "... provides a proper API for dealing with setting a server's hostnames in a standardized way." In other words, they added one more standard. :-) One might also note that since its inception, there are at least a half dozen forks from the project, which probably means a half dozen more additional "standards".
    – UncaAlby
    Commented Jul 10, 2019 at 16:22
  • I'm giving you a +1 just for that handy idiom rpm -qf $(type -P hostnamectl) I've got to remember that one! Commented Oct 7, 2019 at 17:34

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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .