Die Graubärte unter Euch wissen sicher, daß es /etc/hostname gibt. In der Datei steht der Rechnername drin… und dann kam systemd 🙁  Es folgt ein kleiner Rant, wie Verbesserungen auch schlecht sein können.

Anders meint nicht unbedingt besser: hostnamectl

Klassisch trägt man den Rechnernamen in die Datei /etc/hostname ein und die Sache hat sich. Jetzt gibt es aber so Spezialisten, die einen Rechner gerne „Pötterings Spielwiese“ nennen wollen, aber so nicht können. Also dachten sie sich ein 3 Ebenen System aus, bei dem es einen PRETTYNAME mit allen möglichen lustigen Zeichen gibt, dann den STATISCHEN NAMEN mit einem Domainnamen drin und den FALLBACKNAME aus dem Netzwerkstack gibt.

(Das Pöttering im Beispiel steht, hat er übrigens dem MAN PAGE Eintrag zu verdanken 😉 )

Wie wird der Hostname jetzt für die Bash-Shell gesetzt?

In Zeile 82 der /etc/profile  steht :

HOSTNAME=$(/usr/bin/hostnamectl --transient 2>/dev/null) || \
HOSTNAME=$(/usr/bin/hostname 2>/dev/null) || \
HOSTNAME=$(/usr/bin/uname -n)

Der Befehl „/usr/bin/hostnamectl –transient“ zieht sich damit den „flüchtigen“ Namen aus dem Netzwerkstack, dann wird /etc/hostname gefragt, dann als LAST RESORT was auch immer uname so von sich gibt, was auch nichts anderes als der Inhalt von /etc/hostname ist.

Euch ist aufgefallen, daß da „/usr/bin/hostnamectl –transient 2>/dev/null“ steht, also die Fehlerausgaben ins Nirvana umgeleitet werden? Es kann also Fehlermeldungen geben. Wenn die Auftreten ist die STDOUT Ausgabe leer, was dann den Fallback auf „/usr/bin/hostname“ und somit /etc/hostname auslöst.

Wieso kommt es beim Ermitteln des Hostnamen zu einem Fehler?

Weil es dringend eines DBUS Dienstes bedurfte, der umständlich gefragt wird, wie denn der Name aussieht.. etwas, was das hostnamectl Programm auch selbst hätte machen können. ES IST UNSINNIG JOBS via client-server-arch zu erledigen, die mit einem einfachen FOPEN() zu erledigt wären.

Wenn man das schon macht, dann bitte richtig, nämlich erst einmal checken, ob so eine Abfrage überhaupt funktionieren könnte, also ob der Server überhaupt da ist. Jetzt ist das DBUS System keine Direktverbindung zwischen dem Dienst und dem Abfragenden, sondern hat die Rolle des Vermittlers. d.b. hostnamectl schickt die Dbus Anfrage einfach los und wartet auf Antwort.

Was passiert, wenn die nicht kommt?

Das hier:

# time /usr/bin/hostnamectl --transient
Could not get property: Connection timed out

real	0m25.047s
user	0m0.007s
sys	0m0.013s

Und wieso kommt da keine Antwort?

$ ps auxf|grep -c hostnamed
0

Tja, der hostnamed hatte sich aus unbekannten Gründen verabschiedet und konnte nicht mehr antworten.

D.b. das ganze tolle System hängt auf Gedeih und Gedärb davon ab, daß der hostnamed auch läuft. Ein Dienst der nur den Job hat, aus irgendeiner Datei auf Anfrage einen Wert auszulesen. Was das aufrufende Programm auch selbst erledigen könnte, wenn es die Datei einlesen dürfte. Der Hostname ist ja nun wahrlich kein Geheimnis.

Und welche praktischen Auswirkungen hat der Fehler?

/etc/profile wird ja von jeder Bash ausgeführt, die eine interaktive Session bedienen soll, also auch den SSH Zugang zu einem Server. Jetzt dürft Ihr ganz ganz kurz raten, was es bedeutet, wenn der hostnamed auf einem Server nicht mehr antwortet. Genau, JEDER der einloggen will, jedes Cronscript das Bash startet hängt für 25 Sekunden in der Luft. Nur weil jemand einen PRETTYNAME haben wollte und so  blöd war das über DBUS abzuwickeln, statt die richtigen Dateirechte zusetzen!

Das Team um Systemd und ich werden wohl nie Freunde werden.