[gelöst] systemd-networkd - Merkwürdige "Nebeneffekte"

[TomL]

Moin

Auf unbeabsichtigte Anregung an anderer Stelle hier habe ich einfach mal meinen Laptop zum Testrechner gemacht und versucht von /etc/init.d/networking auf systemd-networkd zu wechseln. Ich muss den Rechner wegen der geplanten Luks-Partition eh neu aufsetzen, da habe ich jetzt einfach mal experimentiert. Die Einrichtung war denkbar simpel.... verblüffend war dann , wie reibungslos das Netzwerk via systemd startet, der Rechner ist (subjektiv empfunden) nach halber Zeit am Anmeldebildschirm. Das hat mir schon mal sehr gefallen.

Aber nun das, was jetzt nicht mehr geht.... meine 2 eigenen Service-Units fürs Netzwerk funktionieren nicht mehr, ebenso funktioniert der ssh-Server nicht mehr. Mehrere Minuten nach dem Start dann die Meldung "Bootup is not yet finished. Please try again later".... *hmmm*. Fakt ist, der Rechner ist noch in der Startphase mit beiden Interfaces verbunden, also sowohl eth0 als auch wlan0 habe eine IP.... und trotzdem denken die genannten Services anscheinend "Kein Netz!". Das Journal enthält keine verwertbaren Informationen. Hat jemand eine Idee, wie ich dem Problem auf die Spur kommen kann?

Code: Alles auswählen

systemd-analyze plot >/home/thomas/boot.svg
Bootup is not yet finished. Please try again later.

systemctl --failed --all
0 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: inactive (dead)
   
systemctl status network_wait_online.service
● network_wait_online.service - Waiting for /etc/network/interfaces to be up
   Loaded: loaded (/etc/systemd/system/network_wait_online.service; enabled)
   Active: inactive (dead)   
   
systemctl status mountctrl.service
● mountctrl.service - mountctrl (avoid mount + umount + stop-job-errors)
   Loaded: loaded (/etc/systemd/system/mountctrl.service; enabled)
   Active: inactive (dead)   

Noch ein paar abschliessende Hinweise.... auf die ich mir auch keinen Reim machen kann. Zwischendurch habe ich (mit der systemd-networkd-Konfiguration) einfach mal ssh entfernt und wollte es wieder neu installieren. Keine Chance, apt-get install ließ sich nicht erfolgreich abschließen. OpenSSH wurde geladen und installiert und dann beim Generieren der Schlüssel isses gestorben. dpkg war ab dem Moment gesperrt und weder über apt-get install -f noch über dpkg --configure -a war eine Reparatur möglich. Das OpenSSH-Setup war kaputt und nicht möglich zu beenden.

Ich habe dann die systemd-networkd-Services wieder ausgeplant, das init.d-Script "networking" wieder eingeplant und rebootet. Und siehe da, das SSH-Setup konnte probleme repariert und zum erfolgreichen Ende gebracht werden. Sowohl meine Service-Units als auch ssh.service starteten wieder problemlos.

Was könnte ich tun, ums ans Laufen zu bringen...?.... denn eigentlich finde ich es klasse, wie schnell das Notebook damit startet.

[guennid]

Es juckt mich in den Fingern, TomL, aber 's wär' 'n Insider und würde vielleicht auch als unfair empfunden, deswegen lass' ich's und wünsche stattdessen gutes Gelingen, zu dem ich trotz "unbeabsichtigter Anregung" leider nichts beitragen kann.

[NAB]

Code: Alles auswählen

Waiting for /etc/network/interfaces to be up

Die Datei wird ja anscheinend trotzdem noch ausgewertet. Soll das so sein?

[TomL]

Das ist nur der Description-Text der Unit.... also hier in dem Fehlerzusammenhang bedeutungslos.

[TomL]

Das Problem ist gelöst.... und hat sich im Grundegenommen mal wieder als unnötiges PillePalle-Problem erwiesen. Der Verursacher war natürlich NICHT systemd-networkd, sondern das (ver)alte(te) RunTime-Level-Script /etc/init.d/ssh. Dieses Script hat sich wegen des nun fehlenden/inaktiven Scriptes "networking" und nun unklarer systemd-Reihenfolge natürlich so festgefressen, dass danach eben nix mehr gescheit lief.... eben genau eines dieser Probleme, die unter systemd nicht mehr auftreten sollten.... aber es ist ja eben ein altes Runtime-Level-Script. Nachdem ich nun in die /lib/systemd/system/ssh.service das after-Statement um meine eigene Unit network_wait_online.service

Code: Alles auswählen

After=network.target auditd.service network_wait_online.service

ergänzt habe, läuft das richtig klasse. Ich bin mal wieder begeistert... schneller und besser als zuvor... systemd rocks

[KP97]

Ich hatte ja zuvor schon in Günthers Thread erwähnt, daß alle Scripte in init.d wegfallen können. Systemd hat nämlich für die Standardscripte bereits fertige Services, die man natürlich aktivieren muß. Nur bei eigenen Aktionen muß man Hand anlegen, aber das hast Du ja schon hingekriegt.

[catdog2]

Ich hatte ja zuvor schon in Günthers Thread erwähnt, daß alle Scripte in init.d wegfallen können.

Das ist falsch. Dürfte immer noch Pakete geben, die nur ein init skript mitliefern.

Systemd hat nämlich für die Standardscripte bereits fertige Services, die man natürlich aktivieren muß.

Eigentlich werden systemd services von systemd bevorzugt verwendet, wenn sie existieren, auch bei ssh. Keine Ahnung was da bei TomL falsch gelaufen ist.

[TomL]

Eigentlich werden systemd services von systemd bevorzugt verwendet, wenn sie existieren, auch bei ssh. Keine Ahnung was da bei TomL falsch gelaufen ist.

Ich glaube nicht, dass da was verkehrt gelaufen ist, weil ich da eigentlich nicht wirklich dran rumgeschraubt habe. Der ssh-Daemon wurde bisher ganz normal via ssh.service-Unit gestartet... nur... und das ist wohl die Besonderheit... das, was gestartet wird, ist nix anderers als ein altes sysvinit-Script, welches sich natürlich auf die früher geltende eindeutige sysvinit-Reihenfolge verlassen hat.

Nur ist das jetzt unter systemd anders, der ssh-Daemon wurde nämlich schon gestartet, obwohl das Netz noch nicht da war... weil das neu in Betrieb genommene systemd-networkd das vermutlich jetzt eben gemäß der Parallelisierung in der Bootphase handhabt. Ich werte das so, wie schon in der Vergangenheit, dass eigentlich die Jobs selber gewährleisten müssen, dass sie mit Parallelisierung klar kommen. Früher hatte (i.ü.S.) der Türsteher die Tür geöffnet, bevor der Job dran war... heute müssen sie eben warten, falls die Tür noch geschlossen ist... und genau das tut das ssh-sysvinit-Script nicht... es hat schlichtweg einiges zum erliegen gebracht, weils vermutlich mit dem Kopp solange vor die geschlossene (Netzwerk-)Tür gehämmert hat, bis es ohnmächtig umgekippt ist. *fg*.

Ich habs einfach auf "warten" gestellt, in dem ich der ssh.service-Unit eine entsprechende Abhängigkeit definiert habe. Das war die Lösung.

[catdog2]

Der ssh-Daemon wurde bisher ganz normal via ssh.service-Unit gestartet... nur... und das ist wohl die Besonderheit... das, was gestartet wird, ist nix anderers als ein altes sysvinit-Scrip

Kann ich nicht nachvollziehen:

Code: Alles auswählen

# systemctl cat ssh.service 
# /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify

[Install]
WantedBy=multi-user.target
Alias=sshd.service

[TomL]

Ok... ich seh's ... es wird das Binary gestartet... da war ich wohl (unachtsam) im Irrtum.

Aber dennoch, das Problem ist geblieben.... denn network.target ist NICHT eindeutig definiert.... es kann bedeuten, dass der Network-Manager gestartet ist, der aber noch gar kein Netz geöffnet/verbunden hat. Es kann bedeuten, dass das Netzwerk grundsätzlich gestartet wurde, aber das es noch nicht verbunden ist. Es kann bedeuten, dass z.B. WLAN aktiviert wurde, um vielleicht nach SSID zu scannen, aber bisher ist noch keine IP vergeben. Die Manpage empfiehlt sogar, sich darauf nicht zu verlassen, sondern network-online.target zu verwenden. Der Unterschied ist, network.target ist eine passive Unit, network-online.target ist eine aktive Unit.

Ich verwende an der Stelle heute trotzdem nur meine eigene Unit network_wait_online.service, weil ich die Funktionalität von network-online.target und systemd-networkd-wait-online.service nicht so recht durschaut habe. Und weil ich nicht wusste, ob beide wirklich in beiden Szenarien unterstützt werden, also bei Nutzung /etc/init.d/networking UND/ODER systemd-networkd. So weit ich weiss, konnte ich systemd-networkd-wait-online.service früher nicht verwenden konnte, weil ich ja jetzt gerade erst auf systemd-networkd umgestellt habe. Aber ich werde dennoch bei meiner eigenen Unit bleiben, weil die absolut zuverlässig läuft und ich weiss, was sie tut.

[smutbert]

[…]
Aber dennoch, das Problem ist geblieben.... denn network.target ist NICHT eindeutig definiert.... es kann bedeuten, dass der Network-Manager gestartet ist, der aber noch gar kein Netz geöffnet/verbunden hat. Es kann bedeuten, dass das Netzwerk grundsätzlich gestartet wurde, aber das es noch nicht verbunden ist. Es kann bedeuten […]

Das mit dem »nicht eindeutig definiert« klingt jetzt fast nach systemd-Kritik
Soweit ich mich erinnere hat Poettering gesagt/geschrieben, dass es keine verlässliche Dokumentation gibt - im Zweifelsfall ist die Dokumentation halt falsch oder veraltet und das tatsächliche Verhalten von systemd richtig...


Eigentlich wollte und sollte ich aber nur schreiben, dass »network.target« tatsächlich keine Netzwerkverbindung erfordert und das sowohl nach der mir bekannten Dokumentation (und erst recht per definitionem nach dem Verhalten von systemd) auch ganz korrekt ist.
Für das tatsächliche Bestehen einer Netzwerkverbindung gibt es afaik »network-online.target«. (Nur hat das als ich es das letzte Mal damit versucht habe, ebenfalls nicht richtig geklappt.) Für networkd gibt es außerdem noch »systemd-networkd-wait-online.service«.

[catdog2]

Die Doku sagt, es ist eigentlich nur für den shutdown definiert um vor dem Netzwerk gestoppt zu werden.

[TomL]

Das mit dem »nicht eindeutig definiert« klingt jetzt fast nach systemd-Kritik

Aber nicht doch ich bin von systemd absolut überzeugt. "Nicht eindeutig definiert" sagt die Man-Page: "...but it is only very weakly defined what that is supposed to mean". Ich deute das also in dem Sinne, dass nicht zwingend eine IP vorhanden sein muss, auch wenns angezogen wird.

Eigentlich wollte und sollte ich aber nur schreiben, dass »network.target« tatsächlich keine Netzwerkverbindung erfordert und das sowohl nach der mir bekannten Dokumentation (und erst recht per definitionem nach dem Verhalten von systemd) auch ganz korrekt ist.

Ja, sehe ich auch so. Und dafür gibts ja eben die beiden anderen. Aber...

Für das tatsächliche Bestehen einer Netzwerkverbindung gibt es afaik »network-online.target«. (Nur hat das als ich es das letzte Mal damit versucht habe, ebenfalls nicht richtig geklappt.) Für networkd gibt es außerdem noch »systemd-networkd-wait-online.service«.

... das eine hat -wie du auch bemerkt hast- irgendwie nicht so richtig funktioniert und das andere war wohl an systemd-networkd gekoppelt. Und da ich bisher nicht networkd genutzt habe, musste ich eben was eigenes basteln. Und jetzt nach dem Wechsel zu networkd bleibe ich einfach bei meiner eigenen Lösung... denn die klappt wirklich gut.