qui
Hallo,
wenn ich via `systemd-analyze (blame)` mir die Startzeiten so ansehe, fällt mir folgendes auf:
- Der NetworkManager braucht immer ~ ½ Sekunden.
- dhcpcd@ hingegen benötigt immer 2-3 Sekunden!
Inwieweit sind diese systemd-Werte überhaupt brauchbar? Kann dieses »Mehr« bei dhcpcd evtl. einfach daher kommen, daß dieser bspw. wesentlich früher als der NM starten will, wenn evtl. die NIC/das Netzwerk/… noch gar nicht bereit dafür ist und dementsprechend warten muß? Oder was ganz anderes?
Wäre nett, wenn mir jemand diese Phänomen kurz erläutern könnte. Bei den Messungen waren immer nur NM oder(!) dhcpcd aktiviert, Wechselwirkungen also ausgeschlossen.
Creshal
Ich habe mir die Startskripte nicht angeschaut, aber nm forkt normalerweise fast sofort in den Hintergrund und fängt erst dann an, nach Geräten zu suchen. dhcpcd hingegen stellt erst die Verbindung her und forkt dann erst. Die Startzeit ist entsprechend nicht vergleichbar.
qui
Ok, danke. Das hieße also salopp ausgedrückt, daß NM schon »fertig« plärrt, obwohl dem prinzipiell noch nicht so ist, und dhcpcd hingegen sein »done« wirklich erst raushaut, wenn alles vollständig erledigt ist? Wären dementsprechend diese 2-3 Sekunden im Rahmen des für dieses Prinzip Erwartbaren bzw. »unverdächtigen Normalen«?
Creshal
2-3 Sekunden klingt ziemlich normal, ja.
qui
Alles klar; ich hab' auch nur deshalb nachgefragt, weil die betroffene Kiste halt einfach direkt am Router hängt und somit dhcpcd verglichen mit dem NM eigentlich die passendere bzw. wesentlich schlankere Lösung darstellt.
> Ich habe mir die Startskripte nicht angeschaut, aber nm forkt normalerweise fast sofort in den Hintergrund und fängt erst dann an, nach Geräten zu suchen.
Weshalb wird die anschließende Gerätesuche eigentlich nicht in die Zeitrechnung miteinbezogen? So, wie Du das beschreibst, ist die NM-Startzeit ja mehr oder weniger ein Wert ohne wirkliche Aussagekraft; darf man hier von Halbwahrheiten sprechen?
Creshal
Naja, nm ist ja gestartet. Der eigentliche Verbindungsaufbau ist davon ja entkoppelt und kann u.U. gar nicht stattfinden, wenn bspw. das Kabel fehlt. Bei dhcpcd darfst du dann den 90 Sekunden langen Timeout abwarten, bevor er sich beendet, während nm in der Zwischenzeit einfach im Hintergrund läuft und wartet, dass das Kabel angesteckt wird.
qui
Aha. D.h. also, wenn ich (mal rein hypothetisch zum Verständnis) erst bspw. 10 Minuten nach dem Booten das Ethernetkabel anschließen würde, würde der NM mit seinem Stand-by-Verhalten mir trotzdem umgehend eine Verbindung aufbauen, während ich im Falle von dhcpcd selbigen erst wieder manuell ankurbeln müßte?
Creshal
Jop. Es sei denn, Systemd hat da wieder mal eine eigene Hotplug-Erkennung eingebaut, die das automagisch selber machen kann, sofern du die richtigen Config-Flags gesetzt hast, es keine Bugs gibt und du um Mitternacht bei Neumond Lennart eine dreiköpfige Ziege opferst und "Hastur! Hastur! Hastur!" rufst.
qui
Gut, dann noch mal vielen Dank für deine Erläuterungen.
Die derart mißratene Ziege bekommt man sicherlich im AKW-Shop des Vetrauens, Opferung dürfte, sofern keine Enthauptung vorgesehen ist, auch kein Problem werden, ebenso das wüste Geplärre, aber systemd-Flags setzen? Kraß.
Creshal
😃
qui
Eine kurze Frage hätte ich noch zu dhcpcd, für die sich imho kein neuer Thread rentiert: Weshalb wird dhcpcd von systemd anscheinend per default mit `-A', also der noarp-Option, ausgeführt (siehe dazu bspw. `systemctl status …')? Spekuliert man hier auf den Einsatz in Home-Netzwerken? War das in der Prä-systemd-Ära eigentlich auch schon so?
Und doch noch was zum eigentlichen Thema:
> dhcpcd hingegen stellt erst die Verbindung her und forkt dann erst.
Laut der manpage wird dieses Verhalten wohl durch das Flag `-w' erzielt. Gleiche Frage wie oben: Weshalb ist das (unter systemd) Standard?
Creshal
> War das in der Prä-systemd-Ära eigentlich auch schon so?
cat /etc/conf.d/dhcpcd ?
qui
Liefert folgendes:
DHCPCD_ARGS="-q"
Also dementsprechend nicht, weder a noch w… Nun gut, danke für den Hinweis.
qui
Imho einigermaßen interessanter Nachtrag zu dhcpcd:
Seit neuerstem (bzw. seit dem Update auf 5.6.3?) wird dhcpcd von systemd nun doch auf einmal wieder ohne(!) das NoARP-Flag`-A' gestartet… das erklärt dann wohl auch die neuerdings fast verdoppelten Startzeiten von dhcpcd, zumidest, wenn man `systemd-analyze blame' Glauben schenkt.
Interessant wär' aber schon, weshalb man zwischenzeitlich auf ARP verzichtet hat, es jetzt aber nun doch wieder einsetzt…