Hostname unter Linux dauerhaft ändern: hostnamectl, /etc/hosts und cloud-init

Ein Server, der debian, localhost oder vm-01 heißt, funktioniert einwandfrei. Unangenehm wird es erst, wenn drei davon gleichzeitig laufen, wenn Protokollzeilen nicht mehr auseinanderzuhalten sind oder wenn der erste Mailserver dazukommt und die Gegenstelle den Namen prüft. Diese Anleitung ändert den Hostnamen so, dass er den nächsten Neustart übersteht, dass sudo nicht in ein Zeitlimit läuft und dass auch die Dienste ihn kennen, die ihn beim Start einlesen.

Sie ist die Vertiefung zu Schritt 6 der Checkliste für einen neuen Rootserver. Dort stehen die zwei Befehle, die meistens genügen. Hier steht, was dahinter passiert, und was Sie tun, wenn sie nicht genügen.

Alle Angaben beziehen sich auf Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Die Befehle sind für den Betrieb als root geschrieben. Als normaler Benutzer stellen Sie jedem Befehl sudo voran.

Ein Server hat drei Namen, nicht einen

Der häufigste Grund für eine halb geglückte Umbenennung ist, dass Linux nicht einen Hostnamen kennt, sondern drei. Sie liegen an verschiedenen Orten und werden von verschiedenen Stellen überschrieben.

Den flüchtigen Namen führt der Kernel, ihn bekommt jedes Programm über gethostname(). Der statische Name ist die Vorlage, aus der er beim Hochfahren gesetzt wird. Der sprechende Name darf Leerzeichen und Umlaute enthalten und erscheint nur in Oberflächen, nie im Netzwerk.

Genauso wichtig ist die zweite Unterscheidung: welcher Befehl bezieht seine Antwort woher. Angenommen, in /etc/hostname steht srv01 und in /etc/hosts die Zeile 127.0.1.1 srv01.example.com srv01, dann ergibt sich dieses Bild.

Die entscheidende Zeile ist hostname -f. Der Befehl liest nicht /etc/hostname, sondern nimmt den Kernel-Namen und schickt ihn durch die Namensauflösung. Der vollständige Name kommt also aus /etc/hosts oder aus dem DNS, niemals aus der Hostnamen-Datei. Fast alle Probleme in diesem Artikel gehen auf dieses Missverständnis zurück.

Vor der ersten Änderung: der Rückweg

Eine Umbenennung allein kappt Ihre SSH-Sitzung nicht. Gefährlich ist der Schritt danach: das Bearbeiten von /etc/hosts. Verschwindet dort die Zeile für localhost, warten Dutzende Programme in Zeitlimits, Postfix startet nicht mehr, und sudo braucht Sekunden pro Aufruf. Klären Sie deshalb vorher drei Dinge.

1. Eine zweite Sitzung bleibt offen

Öffnen Sie ein zweites Terminalfenster mit einer aktiven Verbindung und schließen Sie es nicht, bis alles geprüft ist. Eine bestehende Sitzung überlebt jede Änderung an Hostnamen und Namensauflösung. Falls der Verbindungsaufbau selbst noch nicht sauber steht, hilft Per SSH mit dem Server verbinden.

2. Der Weg an SSH vorbei

KVM-Rootserver und Dedicated Server von KernelHost haben kein IPMI und kein iDRAC. Der Zugang, der auch dann noch funktioniert, wenn im Gastsystem nichts mehr geht, ist die VNC-Konsole im Kundenbereich. Sie hängt an der Virtualisierungsschicht beziehungsweise am Anschluss selbst, unabhängig von der Namensauflösung im Gastsystem. Melden Sie sich dort einmal vorher an und vergewissern Sie sich, dass Sie das root-Passwort kennen. Ein Rettungsweg, den man zum ersten Mal im Notfall ausprobiert, ist keiner.

3. Zwei Kopien und eine Rückrolle

cp -a /etc/hostname /root/hostname.bak
cp -a /etc/hosts /root/hosts.bak
hostnamectl > /root/hostnamectl-vorher.txt

Damit ist der Weg zurück ein Zweizeiler, den Sie notfalls über die Konsole eintippen:

cp -a /root/hosts.bak /etc/hosts
hostnamectl set-hostname "$(cat /root/hostname.bak)"

Bestandsaufnahme in fünf Befehlen

Sehen Sie sich zuerst an, was gerade gilt und wer daran mitredet.

hostnamectl
cat /etc/hostname
cat /etc/hosts
grep '^hosts:' /etc/nsswitch.conf
command -v cloud-init >/dev/null && cloud-init status --long || echo "cloud-init nicht installiert"

Auf die Ausgabe von hostnamectl lohnt ein genauer Blick. Normalerweise beginnt sie mit Static hostname:. Taucht zusätzlich eine Zeile Transient hostname: auf, weichen statischer und laufender Name voneinander ab, und etwas setzt den Namen aktiv um: fast immer cloud-init oder ein DHCP-Client. Das gehört zuerst abgestellt, sonst ist Ihre Änderung nach dem nächsten Neustart wieder weg.

Die hosts:-Zeile aus /etc/nsswitch.conf legt die Reihenfolge der Namensauflösung fest. Die vier Einträge, die dort vorkommen, bedeuten:

• files: /etc/hosts wird gelesen.
• dns: der Resolver fragt die Nameserver aus /etc/resolv.conf.
• resolve: die Anfrage geht an systemd-resolved.
• myhostname: ein Modul von systemd, das den eigenen Rechnernamen auf die lokal konfigurierten IP-Adressen abbildet, auch ohne Eintrag in /etc/hosts.

Der letzte Punkt erklärt weiter unten, warum derselbe Fehler auf manchen Servern jahrelang unbemerkt bleibt.

Den Namen wählen: FQDN oder Kurzname

Erlaubt sind Buchstaben, Ziffern und der Bindestrich. Kein Unterstrich, kein Punkt am Anfang oder Ende, kein Bindestrich am Anfang eines Labels. Schreiben Sie klein: DNS vergleicht ohne Rücksicht auf Groß- und Kleinschreibung, viele Programme dagegen wörtlich. Ein Label (der Teil zwischen zwei Punkten) darf 63 Zeichen lang sein, der vollständige Name im DNS 253. Der Kernel nimmt für den Hostnamen allerdings höchstens 64 Zeichen an, ein sehr langer FQDN passt also womöglich gar nicht hinein. Wählen Sie den Namen unterhalb einer Domain, die Ihnen gehört: .local ist für mDNS reserviert, und erfundene Endungen wie .lan können jederzeit zu echten Top-Level-Domains werden.

Bleibt die Frage, was in /etc/hostname steht. Beide Varianten funktionieren, sie unterscheiden sich in dem, was Ihnen danach überall angezeigt wird.

Auf Debian und Ubuntu empfiehlt sich die erste Variante: Kurzname in /etc/hostname, vollständiger Name als erster Eintrag in /etc/hosts. Damit bleiben Prompt und Protokollzeilen kurz, und der FQDN stimmt trotzdem. Die zweite Variante ist ebenso sauber, solange sie konsequent durchgehalten wird. Der eigentliche Fehler ist die Mischung: ein FQDN in /etc/hostname und ein anderer in /etc/hosts.

Legen Sie den A-Eintrag (bei IPv6 den AAAA-Eintrag) für den neuen Namen am besten jetzt an. Er kostet nichts, macht hostname -f auch ohne /etc/hosts richtig und ist die Voraussetzung für jedes Zertifikat auf diesen Namen.

cloud-init zähmen, bevor Sie etwas setzen

Auf Abbildern mit cloud-init, und das sind bei Ubuntu praktisch alle, wird der Hostname beim Hochfahren aus den Metadaten der Instanz gesetzt. Zuständig sind die Module set_hostname und update_hostname, dazu update_etc_hosts für die Datei /etc/hosts. Alle drei laufen früh, noch bevor Ihre eigenen Dienste starten. Zwei Schalter steuern das:

grep -rE '^(preserve_hostname|manage_etc_hosts)' /etc/cloud/cloud.cfg /etc/cloud/cloud.cfg.d/ 2>/dev/null

Auf Ubuntu-Server-Abbildern steht in /etc/cloud/cloud.cfg die Zeile preserve_hostname: false, cloud-init darf den Namen also anfassen. Der Gegenschalter gehört nicht in diese Datei, weil eine Paketaktualisierung sie ersetzt, sondern nach /etc/cloud/cloud.cfg.d/. Die Dateien dort werden alphabetisch gelesen, die spätere gewinnt, daher die 99:

mkdir -p /etc/cloud/cloud.cfg.d
printf 'preserve_hostname: true\n' > /etc/cloud/cloud.cfg.d/99_hostname.cfg

Der zweite Schalter betrifft /etc/hosts. Er wird gerne übersehen, obwohl er mehr Schaden anrichtet.

Steht dort true und Sie brauchen eigene Einträge, setzen Sie den Wert auf localhost oder pflegen Sie stattdessen die Vorlage (auf Debian und Ubuntu hosts.debian.tmpl). Eine Datei von Hand zu ändern, die bei jedem Start überschrieben wird, erzeugt genau die Sorte Fehler, die man erst Wochen später bemerkt.

Was cloud-init zuletzt gesetzt hat, merkt es sich unter /var/lib/cloud/data/. Diesen Zustand löscht cloud-init clean. Tun Sie das auf einem eingerichteten Server bitte nicht: beim nächsten Start laufen sämtliche Module wieder an, als wäre die Maschine neu.

Der zweite Umschreiber: DHCP

Bezieht der Server seine Adresse per DHCP, kann der Client den flüchtigen Hostnamen aus der Antwort übernehmen (Option 12). Der statische Name bleibt unangetastet, was die Fehlersuche erschwert: hostnamectl --static zeigt Ihren Namen, hostname einen anderen. Unter netplan schalten Sie das ab:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-hostname: false

Aktivieren Sie mit netplan try statt netplan apply: try nimmt die Änderung nach 120 Sekunden von selbst zurück, wenn Sie nicht bestätigen. Bei direkt konfiguriertem systemd-networkd heißt die Einstellung UseHostname=no im Abschnitt [DHCPv4].

Den Hostnamen setzen

hostnamectl set-hostname srv01

Ohne weitere Schalter setzt hostnamectl den statischen und den flüchtigen Namen gemeinsam. Genau das wollen Sie. Mit --static ändern Sie nur /etc/hostname, und bei aktivem flüchtigem Namen liefe die Maschine bis zum Neustart unter dem alten weiter. Neuere systemd-Versionen kennen zusätzlich die Kurzform hostnamectl hostname srv01, set-hostname funktioniert auf allen vier Systemen.

Erfolgskontrolle: beide Namen müssen übereinstimmen und die Datei den neuen Inhalt tragen.

hostnamectl --static
hostnamectl --transient
cat /etc/hostname

Zwei Randbemerkungen. Erstens ändert hostname srv01 ohne ctl nur den flüchtigen Namen und ist nach dem Neustart verschwunden. Zweitens zeigt Ihre laufende Shell weiterhin den alten Namen im Prompt, weil bash den Hostnamen einmal beim Start der Sitzung einliest. Das ist kein Fehlschlag, sondern eine alte Sitzung. Melden Sie sich neu an.

Optional hinterlegen Sie einen sprechenden Namen, der in Oberflächen erscheint und Leerzeichen enthalten darf:

hostnamectl set-hostname --pretty "Webserver Frankfurt"
cat /etc/machine-info

/etc/hosts richtig schreiben

hostnamectl fasst /etc/hosts nicht an. Diese Datei bleibt Ihre Aufgabe, und sie ist der Grund, warum eine Umbenennung so oft nur halb wirkt.

Eine Zeile besteht aus einer IP-Adresse, dem kanonischen Namen und beliebig vielen Aliassen. Der erste Name nach der Adresse ist der kanonische, und genau ihn liefert hostname -f. Deshalb steht der vollständige Name vorn und der Kurzname dahinter, nie umgekehrt.

127.0.0.1       localhost
127.0.1.1       srv01.example.com srv01

::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Warum 127.0.1.1 und nicht 127.0.0.1: Debian und Ubuntu trennen den eigenen Rechnernamen bewusst von localhost. Hängen Sie den Servernamen als Alias an die localhost-Zeile, bleibt deren kanonischer Name localhost, und hostname -f antwortet mit localhost. Programme, die daraus ihren eigenen Namen ableiten, tragen anschließend localhost in Protokolle und E-Mail-Kopfzeilen ein.

Einen fehlenden Eintrag hängen Sie an, eine vorhandene Zeile ändern Sie:

grep -n '^127\.0\.1\.1' /etc/hosts
printf '127.0.1.1\tsrv01.example.com\tsrv01\n' >> /etc/hosts

Gibt der erste Befehl bereits eine Zeile aus, bearbeiten Sie diese, statt eine zweite anzuhängen. Bei zwei Zeilen für dieselbe Adresse gewinnt die erste, und Sie ändern danach eine Zeile, die niemand mehr liest.

Erfolgskontrolle:

getent hosts srv01
getent hosts srv01.example.com
hostname -f
hostname -s

Die beiden getent-Aufrufe müssen je eine Zeile liefern, hostname -f den vollständigen und hostname -s den Kurznamen. Kommt nichts zurück, ist der Eintrag nicht wirksam, etwa weil die Zeile ein Kommentarzeichen trägt.

Eine Entscheidung bleibt: 127.0.1.1 oder die öffentliche Adresse des Servers. Manche Software bindet sich an die Adresse, auf die ihr eigener Name auflöst, oder trägt sie in die Mitgliederliste eines Verbunds ein. Dann gehört der FQDN auf die öffentliche Adresse. Bei fester Adresse ist das die sauberere Variante, bei wechselnder die 127.0.1.1, weil sie auch ohne Netzverbindung funktioniert.

Warum ein fehlender Eintrag sudo langsam macht

sudo ermittelt bei jedem Aufruf den eigenen Rechnernamen und lässt ihn auflösen. Es braucht ihn für die Protokollzeile und für den Abgleich mit den Rechnerangaben in /etc/sudoers.

Die Auflösung läuft entlang der hosts:-Zeile aus /etc/nsswitch.conf. Steht der Name in /etc/hosts, ist die Sache nach einem Dateizugriff erledigt, also in unter einer Millisekunde. Steht er nicht dort, wandert die Anfrage zum nächsten Eintrag, in der Regel dns, und der Resolver fragt die Nameserver aus /etc/resolv.conf nach einem Namen, den es im DNS nicht gibt. Die Voreinstellungen von glibc sind fünf Sekunden Zeitlimit und zwei Versuche je Nameserver. Antwortet niemand, summiert sich das, und zwar bei jedem einzelnen Aufruf.

Verstärkend kommt hinzu: Ein Kurzname enthält keinen Punkt und liegt damit unter der Voreinstellung ndots:1. Der Resolver hängt deshalb zuerst jede Suchdomain aus /etc/resolv.conf an und fragt erst danach den Namen selbst ab. Zwei Suchdomains bedeuten drei Anfragerunden statt einer.

Sichtbar wird das an dieser Warnung, die jedem Aufruf vorangestellt wird:

sudo: unable to resolve host srv01: Name or service not known

Messen statt schätzen:

time getent hosts "$(hostname)"
time sudo -n true

Beides sollte weit unter einer Zehntelsekunde bleiben. Alles darüber ist Wartezeit auf einen Nameserver.

Und jetzt der Grund, warum der Fehler nicht überall auffällt: Steht in der hosts:-Zeile der Eintrag myhostname, beantwortet dieses Modul die Anfrage nach dem eigenen Namen selbst, ohne DNS und ohne /etc/hosts. Dort bleibt die Warnung aus, obwohl die Datei unvollständig ist. Sobald derselbe Aufbau auf ein System ohne diesen Eintrag wandert, ist der Fehler wieder da.

Ein zweites, selteneres Problem betrifft die Rechtevergabe: In /etc/sudoers kann jede Regel auf bestimmte Rechnernamen eingeschränkt sein. Die mitgelieferten Regeln von Debian und Ubuntu verwenden ALL und sind unkritisch. Eigene Regeln mit einem Rechnernamen verlieren dagegen ihre Wirkung, und der betroffene Benutzer darf anschließend nichts mehr. Vorher nachsehen:

grep -rhvE '^[[:space:]]*(#|$)' /etc/sudoers /etc/sudoers.d/

Dienste, die den Namen beim Start einlesen

Viele Programme fragen den Hostnamen genau einmal ab, beim Start, und arbeiten danach mit dem alten Namen weiter. Das erklärt einen guten Teil der Verwirrung nach einer Umbenennung.

• Die laufende Shell. Der Prompt zeigt den alten Namen. Neue Sitzung öffnen, fertig.
• rsyslog, wo es installiert ist. Ein systemctl restart rsyslog genügt. Debian 12 und 13 bringen in minimalen Installationen kein rsyslog mit, dort schreibt journald.
• Bereits geschriebene Protokolleinträge behalten den alten Namen, und das ist richtig so. Steht der alte Name dagegen in neuen Einträgen, starten Sie den schreibenden Dienst neu.
• MariaDB und MySQL leiten Standarddateinamen wie Fehlerprotokoll und Binärlog vom Hostnamen ab, sofern die Pfade nicht ausdrücklich in der Konfiguration stehen.
• Java-Anwendungen. InetAddress.getLocalHost() wirft eine java.net.UnknownHostException, sobald der eigene Name nicht auflöst. Betroffen sind Anwendungsserver ebenso wie Spieleserver.
• Überwachungsagenten tragen den Namen häufig in ihrer eigenen Konfigurationsdatei. Sonst taucht derselbe Server nach der Umbenennung zweimal auf.

systemctl list-units --type=service --state=running

Steht ohnehin ein Wartungsfenster an, ist ein Neustart die vollständigste Lösung. Wie Sie eigene Programme sauber als Unit hinterlegen, damit sie einen Neustart überstehen, steht in systemd-Service erstellen.

Mailserver: der Name, den andere sehen

Beim Mailversand ist der Hostname keine Kosmetik mehr. Die Gegenstelle sieht ihn im EHLO und prüft ihn. Drei Dinge müssen zusammenpassen:

1. Der Name, mit dem sich Ihr Mailserver meldet (bei Postfix myhostname).
2. Der PTR-Eintrag Ihrer IP-Adresse, also die Rückwärtsauflösung.
3. Ein A-Eintrag (bei IPv6 ein AAAA-Eintrag) für genau diesen Namen, der wieder auf dieselbe Adresse zeigt.

Schließt die Kette nicht, stufen viele Empfänger die Nachricht herab oder weisen sie ab. Prüfen ohne zusätzliche Pakete:

hostname -f
getent hosts 203.0.113.10
getent hosts srv01.example.com

Genauer wird es mit dig aus dem Paket bind9-dnsutils:

apt install -y bind9-dnsutils
dig +short -x 203.0.113.10
dig +short srv01.example.com A

Der PTR-Eintrag gehört nicht dem Server. Er hängt an der IP-Adresse und wird beim Betreiber des Netzes gepflegt, bei KernelHost über den Kundenbereich. Kein Aufruf von hostnamectl ändert daran etwas, und genau hier gehen Umbenennungen bei Mailservern schief.

Postfix übernimmt die Umbenennung nicht von selbst. Auf Debian und Ubuntu schreibt das Paket beim Einrichten einen festen Wert nach /etc/postfix/main.cf, daneben liegt /etc/mailname mit dem Namen, den Postfix als Absenderdomain für lokale Post verwendet. Beide bleiben unverändert stehen:

postconf myhostname mydomain myorigin
cat /etc/mailname

Anpassen und neu starten, wobei /etc/mailname eine eigene Entscheidung ist und nicht zwingend denselben Wert trägt wie myhostname:

postconf -e "myhostname = srv01.example.com"
postfix check
systemctl restart postfix

SPF, DKIM und DMARC hängen dagegen an der Absenderdomain und nicht am Hostnamen. Eine Umbenennung repariert also keine Zustellprobleme, deren Ursache dort liegt.

Zertifikate

Der Systemname steht in keinem Zertifikat, denn ein Zertifikat deckt die DNS-Namen ab, die im Antrag standen. Trotzdem schlägt eine Umbenennung an drei Stellen durch.

Erstens beim Antrag. Holen Sie ein Zertifikat auf den Servernamen selbst, etwa für den Mailserver, muss der Name im DNS stehen, bevor die Zertifizierungsstelle nachsieht. Sonst endet der Lauf mit einer Meldung wie DNS problem: NXDOMAIN looking up A for srv01.example.com. Der A-Eintrag gehört vor den Antrag, nicht danach.

Zweitens bei den vorhandenen Zertifikaten. Sie laufen auf den alten Namen weiter und werden weiter verlängert, bis Sie sie entfernen:

certbot certificates
certbot delete --cert-name alt.example.com

Löschen Sie erst, wenn kein Dienst mehr auf den Pfad zeigt, sonst startet der Webserver beim nächsten Neuladen nicht mehr.

Drittens beim Mailserver. Meldet sich Postfix mit dem neuen Namen, präsentiert aber ein Zertifikat für den alten, scheitern Gegenstellen, die den Namen streng prüfen. Zertifikat und myhostname gehören auf denselben Namen.

Keinen Zusammenhang gibt es zwischen dem Systemnamen und server_name in nginx. nginx entscheidet anhand des Host-Kopfs der Anfrage, nicht anhand des Rechnernamens. Wer nach einer Umbenennung die falsche Seite ausgeliefert bekommt, sucht in der Serverkonfiguration, nicht beim Hostnamen. Grundlagen dazu in nginx installieren unter Debian und Ubuntu.

Häufige Fehler und Lösungen

sudo: unable to resolve host srv01: Name or service not known
Der Rechnername steht nicht in /etc/hosts und ist im DNS unbekannt. Zeile 127.0.1.1 srv01.example.com srv01 ergänzen. Solange sie fehlt, wartet jeder Aufruf auf ein Zeitlimit des Resolvers.

hostname: Name or service not known
Die Antwort von hostname -f, wenn der Kernel-Name nirgends aufgelöst werden kann. Dieselbe Ursache, dieselbe Lösung. Danach mit getent hosts "$(hostname)" prüfen, ob wirklich etwas zurückkommt.

Could not set property: Access denied
hostnamectl wurde ohne root-Rechte aufgerufen, oder der Aufruf lief in einem Container, der den Kernel-Namen nicht ändern darf. Auf einem eigenen Server hilft sudo. In einem unprivilegierten Container setzen Sie den Namen in dessen Konfiguration, nicht darin.

fatal: unable to use my own hostname
Aus dem Postfix-Protokoll. Der Wert in myhostname löst nicht auf. Eintrag in /etc/hosts ergänzen, danach systemctl restart postfix.

504 5.5.2 <srv01>: Helo command rejected: need fully-qualified hostname
Ihr Mailserver meldet sich mit dem Kurznamen, die Gegenstelle verlangt einen vollständigen Namen. myhostname auf den FQDN setzen und Postfix neu starten.

450 4.7.1 Client host rejected: cannot find your reverse hostname
Zu Ihrer IP-Adresse existiert kein PTR-Eintrag oder er zeigt ins Leere. Das lässt sich nicht auf dem Server beheben, sondern nur beim Betreiber des IP-Netzes.

java.net.UnknownHostException: srv01
Eine Java-Anwendung wollte ihren eigenen Namen auflösen und ist gescheitert. Wieder /etc/hosts. Nach dem Eintrag muss die Anwendung neu gestartet werden.

DNS problem: NXDOMAIN looking up A for srv01.example.com
Der neue Name existiert im DNS noch nicht. A-Eintrag anlegen, Verbreitung abwarten, Antrag wiederholen.

Der Name ist nach dem Neustart wieder der alte.
In dieser Reihenfolge prüfen: Ist preserve_hostname: true unter /etc/cloud/cloud.cfg.d/ gesetzt, liefert der DHCP-Client keinen Namen mehr, enthält /etc/hostname tatsächlich den neuen Namen. Zeigt hostnamectl nach dem Start eine Zeile Transient hostname:, greift noch eine dieser Quellen.

/etc/hosts ist nach jedem Neustart wieder leer geräumt.
manage_etc_hosts: true ist gesetzt, cloud-init erzeugt die Datei aus der Vorlage neu. Auf localhost umstellen oder die Vorlage pflegen.

Distributionsunterschiede

Auf allen vier Systemen gleich: hostnamectl ändert niemals /etc/hosts, und kein Werkzeug des Betriebssystems legt DNS- oder PTR-Einträge an. Diese beiden Schritte bleiben Handarbeit.

Die Abschlusskontrolle

Ein Befehl ohne Fehlermeldung ist kein Nachweis. Der einzige belastbare Test ist der Neustart, danach diese fünf Zeilen:

hostnamectl --static
hostname -f
getent hosts "$(hostname)"
time sudo -n true
grep -c '^127\.0\.1\.1' /etc/hosts

Erwartet werden: der neue Kurzname, der neue vollständige Name, eine Zeile aus /etc/hosts, eine Laufzeit deutlich unter einer Zehntelsekunde und genau eine Zeile für 127.0.1.1. Erst wenn alle fünf stimmen, ist die Umbenennung durch, und erst dann dürfen Sie das zweite Terminalfenster schließen.