Systemd, ein Rant

Smalltalk
Benutzeravatar
whisper
Beiträge: 2235
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Systemd, ein Rant

Beitrag von whisper » 10.07.2018 14:02:24

Bin gerade über http://www.danisch.de/blog/2018/07/10/s ... scheidung/
gestolpert.
Ein Punkt daraus
Das Debugging ist eine Katastrophe. Immer wieder passiert es, dass irgendein System beim Booten an irgendwas hängt, aber nicht sagt, was. Auf der Console wird angezeigt, dass man jetzt auf einen wichtigen Job wartet – aber nicht, auf welchen.
Das habe ich ab- und an auch und ist schon nervig.
Es gibt auch einen Timeout, dann geht es meist weiter.
Diesen "Manchmal" Fehler einzugrenzen ist bestimmt möglich, aber könnte mit entsprechenden Hinweisen viel schneller und einfacher sein.

So tief drin stecke ich nicht im Startupsystem, weiß nur, das war früher leihter zu durchschauen und damit konnte man auch leichter helfend eingreifen.
Wenn ich aber bei Debian bleiben will (und das will ich) kann man nur hoffen, dass das systemd Universum langsam abkühlt und bewohnbar wird :x

Benutzeravatar
heisenberg
Beiträge: 1314
Registriert: 04.06.2015 01:17:27

Re: Systemd, ein Rant

Beitrag von heisenberg » 10.07.2018 14:25:58

Meine Erfahrungen sind da folgende(So wirklich tief drin bin ich auch nicht):
  • Ich hatte schon mal ein Problem mit einem Drucker-/Scannertreiber(3rd-party), der das System in einer der nächsten Systemstarts lahmgelegt hat. Ich habe auf Verdacht via rescue mal rc.local gelöscht. Dann ging es wieder.
  • Ein Server ist irgendwann nicht mehr gestartet.(Wartet auf Dienst irgendwas). Ich habe auch über die Debug-Konsole versucht da Informationen rauszubekommen, was denn da jetzt wirklich klemmt. Selbst nach viel Recherche, wie ich das jetzt debuggen kann nicht hinbekommen. In Hilflosigkeit kurzerhand das Backup eingespielt fertig.
  • Ansonsten ist das Einrichten von neuen Systemdiensten sehr einfach und angenehm.

MSfree
Beiträge: 3470
Registriert: 25.09.2007 19:59:30

Re: Systemd, ein Rant

Beitrag von MSfree » 10.07.2018 14:55:27

Das erinnert mich an eine berühmte Fehlermelldung, die bei Windows NT4 nervenderweise auftrat:
Der Start eines Dienstes, der beim Systemstart gestartet werden sollte, schlug fehl. :facepalm:
In keinem Log war rauszufinden, weilcher Dienst gemeint sein könnte.

Bisher konnte ich Startproblem allerdings in der Regel mit systemd-analyze lösen, zumindest, wenn die Krücke noch bis zum Login kam.

Benutzeravatar
whisper
Beiträge: 2235
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Systemd, ein Rant

Beitrag von whisper » 10.07.2018 15:01:21

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 14:55:27
Bisher konnte ich Startproblem allerdings in der Regel mit systemd-analyze lösen, zumindest, wenn die Krücke noch bis zum Login kam.
Dumm nur, wenn's beim runterfahren passiert. Mal sehen, ob ich dann beim Hochfahren mit systemd-analyze weiterkomme :mrgreen:

Benutzeravatar
Meillo
Moderator
Beiträge: 5051
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Systemd, ein Rant

Beitrag von Meillo » 10.07.2018 15:18:02

Ich finde es gut, wenn mit etwas Abstand die Entscheidungen von damals neu bewertet werden, um fuer zukuenftige Entscheidungen zu lernen.

Ob man bereits genug Abstand hat, kann ich schlecht beurteilen. Der Blogpost scheint mir auch keine sachliche Neubewertung der Situation zu sein. Es waere einfach gut, wenn so ein kontroverses Thema wie Systemd zu gegebener Zeit ordentlich aufgearbeitet werden wuerde.
Use ed(1) once in a while!

Benutzeravatar
Lord_Carlos
Beiträge: 4188
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Systemd, ein Rant

Beitrag von Lord_Carlos » 10.07.2018 15:44:57

Beispielsweise übernimmt das Ding die DNS-Auflösefunktion, aber es gibt da überhaupt nichts zu konfigurieren.
Ist das nicht optional?
Und konfigurieren kann man es auch.
Bei Ubuntu schaffen sie es nicht, den dnsmasq erst dann zu starten, wenn die interfaces alle oben sind – deshalb werden manche Interfaces nicht bedient, weil sie beim Start des Daemons noch nicht da waren.
Systemd will wohl das die Programme selber etwas dynamischer sind. https://www.freedesktop.org/wiki/Softwa ... orkTarget/
If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. You also make the boot faster for your users, as they don't have to delay arbitrary services for the network anymore (which is particularly annoying for folks with slow address assignment replies from a DHCP server).

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Systemd, ein Rant

Beitrag von TomL » 10.07.2018 16:00:44

Meillo hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 15:18:02
Es waere einfach gut, wenn so ein kontroverses Thema wie Systemd zu gegebener Zeit ordentlich aufgearbeitet werden wuerde.
Ich halte das für sehr schwer.... für mich wäre das so, als würden C-Programmierer (die nicht umsteigen wollen), und C++-Programmierer (die umgestiegen sind und die Vorteile begriffen haben) über den Sinn oder Unsinn von C++ diskutieren. Was meiner Meinung nach die Diskussion so schwer macht, ist die Tatsache, dass nicht verifiziert werden kann, was tatsächlich die Ursache vermeintlicher Customizing-Probleme mit systemd ist - echte Bugs mal außen vor gelassen. So Aussagen wie "systemd kriegt's nicht hin" und "der Service wartet nicht auf den Service" oder "systemd hängt beim Start oder beim Stop" lassen mich immer zuerst vermuten, dass es lediglich der Unit-Programmierer nicht hinkriegt, sich in seiner Unit so zu äußern, dass es keine Konflikte gibt. Ich habe echt schon einige verrückte Abhängigkeiten hingebastelt und mich jedesmal gewundert, dass systemd damit klar kommt... einschließlich der Einbindung systemseits bereits vorhandener Units. Das irgendwer nicht auf irgendwen gewartet hat, hab ich noch nie erlebt... nur dann, wenn der Dienst selber ne Macke hatte und nicht mit sauberen Exit-Code zurückgekehrt ist. Und wenn meine Programme Abhängigkeiten haben, dann ist es meine Überzeugung, dass das Warten auf die Abhängigkeit Sache meines Programms bzw. der dazugehörigen Unit ist... das ist nicht Sache von systemd .... mein Programm muss eben selber checken, ob das verfügbar ist, was es braucht, ansonsten warten oder beenden. Mit der Erwartungshaltung von sysvinit kann das aber nix werden, weil man bei sysvinit durch die starr lineare Reihenfolge davon ausgehen konnte, wenn 'mein' Job gestartet wird, sind auch die Abhängigkeiten erfüllt. In Wahrheit ist das mit den Parallelstarts unter systemd also ein Paradigmenwechsel, den sich meiner Meinung einige weigern zu aktzeptieren oder sich anzupassen. Das ist m.M.n. keine gute Basis für eine Diskussion.

Wenn jemand mit dem Herzen C-Programmierer ist, aber mit C++ arbeiten muss, wird er nie die Vorteile von C++ hervorheben, sondern nur auf jeden Fehler rumreiten. Wie gesagt, ich halte das für ein unlösbares Thema, weil persönliche Neigungen es unlösbar machen....insofern kann ein solch kontroverses Gespräch nur schwer konstruktiv sein. Ich teile die Meinung dieses Bloggers nicht... und er ist auch nicht sachlich überzeugend... imho ist das nur 'ne Meinung.... und er hat nicht nachgewiesen, dass er nicht vielleicht selber Ursache der Probeme ist.

j.m2.c.
Zuletzt geändert von TomL am 10.07.2018 16:05:42, insgesamt 1-mal geändert.
vg, Thomas

MSfree
Beiträge: 3470
Registriert: 25.09.2007 19:59:30

Re: Systemd, ein Rant

Beitrag von MSfree » 10.07.2018 16:05:00

Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 15:44:57
If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. You also make the boot faster for your users, as they don't have to delay arbitrary services for the network anymore (which is particularly annoying for folks with slow address assignment replies from a DHCP server).
Wenn ich so etwas lese, kann ich eigentlich nur noch an die Decke gehen. Da hat jemand (Poettering?) mal wieder viel zu kurz gedacht. Wenn ein Dienst wie ein DHCP-Sever (und dnsmasq gehört in diese Kategorie) IP-Adressen nur auf einem Interface ausliefern soll und ein zweites bitte in Ruhe lassen soll, wäre es schon nett, wenn dieser Dienst erst gestartet wird, wenn das Netzwerk vollständig da ist. Warum dnsmasq bei Ubuntu nicht startet, wenn das Netzwerk oben ist, liegt an einer Fehlkonfiguration in der .service-Datei für Systemd. Eine schlampig definierte Starthierarchie damit zu entschuldigen, daß dann der Systemstart schneller ist, zeugt nicht gerade von Weitsicht.

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Systemd, ein Rant

Beitrag von TomL » 10.07.2018 16:08:16

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:05:00
Warum dnsmasq bei Ubuntu nicht startet, wenn das Netzwerk oben ist, liegt an einer Fehlkonfiguration in der .service-Datei für Systemd. Eine schlampig definierte Starthierarchie damit zu entschuldigen, daß dann der Systemstart schneller ist, zeugt nicht gerade von Weitsicht.
Und was hat systemd damit zu tun, wenn der Entwickler von dnsmasq seine Units nicht ordentlich hinkriegt? Und nix anderes steht da imho im von Carlos zitierten Text.... der Entwickler muss sein Programm so hinstellen, dass es mit parallelen Starts von Services klarkommt. Also... systemd kann man das imho bestimmt nicht anlasten....
vg, Thomas

Benutzeravatar
Lord_Carlos
Beiträge: 4188
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Systemd, ein Rant

Beitrag von Lord_Carlos » 10.07.2018 16:13:29

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:05:00
Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 15:44:57
If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. You also make the boot faster for your users, as they don't have to delay arbitrary services for the network anymore (which is particularly annoying for folks with slow address assignment replies from a DHCP server).
Wenn ich so etwas lese, kann ich eigentlich nur noch an die Decke gehen. Da hat jemand (Poettering?) mal wieder viel zu kurz gedacht. Wenn ein Dienst wie ein DHCP-Sever (und dnsmasq gehört in diese Kategorie) IP-Adressen nur auf einem Interface ausliefern soll und ein zweites bitte in Ruhe lassen soll, wäre es schon nett, wenn dieser Dienst erst gestartet wird, wenn das Netzwerk vollständig da ist.
Waere es nicht optimal wenn der DHCP-Sever selber sieht ob das interface da ist oder nicht?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

MSfree
Beiträge: 3470
Registriert: 25.09.2007 19:59:30

Re: Systemd, ein Rant

Beitrag von MSfree » 10.07.2018 16:36:19

Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:13:29
Waere es nicht optimal wenn der DHCP-Sever selber sieht ob das interface da ist oder nicht?
Optimal wäre es sicherlich nicht.

Dnsmasq kann man in der Konfiguration mitteilen, welches Interface mit DHCP versorgt werden soll. Wenn ich sowieso nur ein Interface habe, lasse ich die Option weg und alles ist gut. Habe ich mehrere müßte ich eine Warteschleife ins Programm bauen, die in regelmässigen Abständen prüft, ob die Schnittstelle, die in der Konfiguration steht, bereits hochgefahren ist. Erwische ich dann die Schnittstelle noch in einem halbhochgefahrenen Moment, kommt es darauf an, ob das erkennbar ist und nochmal gewartet werden muß oder ob es dann mit der halben Konfiguration weiter geht und dnsmasq dann einfach nicht funktioniert oder sich beendet.

Es gibt im Kernel jedenfalls keine Funktion, mit der man ein Programm einfach solange warten lassen kann, bis eine bestimmte Bedingung (wie Schnittstelle ist vollständig konfiguriert) erfüllt ist. Das muß das Programm mit Polling machen und Polling ist eine der schlechtesten Testmethoden, die sogar viel Rechenzeit verbraten kann, wenn man es falsch macht, was den Startvorgang sogar verlängern kann.

Systemd und die .service-Dateien unterstützen ja den Fall, daß eine Unit erst gestartet werden soll, wenn eine Bedingung erfüllt ist. Und das ist meines Erachtens der korrekte Weg, auch wenn es ein paar zehntel Sekunden Startzeit kostet.

tobo
Beiträge: 542
Registriert: 10.12.2008 10:51:41

Re: Systemd, ein Rant

Beitrag von tobo » 10.07.2018 17:08:44

TomL hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:00:44
Meillo hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 15:18:02
Es waere einfach gut, wenn so ein kontroverses Thema wie Systemd zu gegebener Zeit ordentlich aufgearbeitet werden wuerde.
Ich halte das für sehr schwer.... für mich wäre das so, als würden C-Programmierer (die nicht umsteigen wollen), und C++-Programmierer (die umgestiegen sind und die Vorteile begriffen haben) über den Sinn oder Unsinn von C++ diskutieren.
Das ist doch mal ein richtig schönes Beispiel dafür, warum man mit populistischen Meinungsmaschinen keinen Dialog führen kann: Das Ergebnis der Diskussion steht bereits vor deren Beginn fest und schwingt in jeder Argumentation mit.

Benutzeravatar
whisper
Beiträge: 2235
Registriert: 23.09.2002 14:32:21
Lizenz eigener Beiträge: GNU Free Documentation License
Kontaktdaten:

Re: Systemd, ein Rant

Beitrag von whisper » 10.07.2018 17:30:21

Eigentlich hätte ich wissen müssen, dass ich damit eine gerade eingeschlafene Diskussion erneut entfache...

Mein Anliegen war, darauf hinzuweisen, dass das System noch Ecken und Kanten hat. Wie ich nun lese, ist das zu kurz gegriffen, das Problem liegt wohl an der Umsetzung von Annahmen bei anderen Diensten und bei der Akzeptanz bei den Endusern.

Als solchen User begreife ich mich hier.
Es ist schön, dass manche Dinge nun (eigentlich) viel schneller erledigt sind (War es bis vor einigen Wochen ja auch, Boot in 4.x Sekunden)
Nur fahre ich jetzt Buster, (selber schuld) und da ist es momentan so, dass beim rebooten in beiden Phasen starke Verzögerungen (nicht immer) auftreten, die ich zwar aushalten, aber nicht unbedingt gut heißen muss.

Benutzeravatar
Lord_Carlos
Beiträge: 4188
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Systemd, ein Rant

Beitrag von Lord_Carlos » 10.07.2018 17:38:22

MSfree hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:36:19
Dnsmasq kann man in der Konfiguration mitteilen, welches Interface mit DHCP versorgt werden soll. Wenn ich sowieso nur ein Interface habe, lasse ich die Option weg und alles ist gut. Habe ich mehrere müßte ich eine Warteschleife ins Programm bauen, die in regelmässigen Abständen prüft, ob die Schnittstelle, die in der Konfiguration steht, bereits hochgefahren ist. Erwische ich dann die Schnittstelle noch in einem halbhochgefahrenen Moment, kommt es darauf an, ob das erkennbar ist und nochmal gewartet werden muß oder ob es dann mit der halben Konfiguration weiter geht und dnsmasq dann einfach nicht funktioniert oder sich beendet.
Muss man nicht sowieso was aehnliches machen um Situationen zu hantieren wie z.B. Netzwerk wechsel?
MSfree hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 16:36:19
Es gibt im Kernel jedenfalls keine Funktion, mit der man ein Programm einfach solange warten lassen kann, bis eine bestimmte Bedingung (wie Schnittstelle ist vollständig konfiguriert) erfüllt ist. Das muß das Programm mit Polling machen und Polling ist eine der schlechtesten Testmethoden, die sogar viel Rechenzeit verbraten kann, wenn man es falsch macht, was den Startvorgang sogar verlängern kann.
In der doku steht was von rtnetlink, das ist nicht dafuer gedacht?
Kann es wirklich viel Rechenzeit kosten jede Sekunde nachzufragen ob ein interface up ist?

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

MSfree
Beiträge: 3470
Registriert: 25.09.2007 19:59:30

Re: Systemd, ein Rant

Beitrag von MSfree » 10.07.2018 18:25:14

Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
10.07.2018 17:38:22
Muss man nicht sowieso was aehnliches machen um Situationen zu hantieren wie z.B. Netzwerk wechsel?
Es kommt drauf an, ob es sich im einen Client oder einen Server handelt. Ein Server wird selten das Netzwerk wechseln, so daß sich das Problem hier eigentlich nicht stellen sollte. Grundsätzlich verlangen alle Serverdienste, egal ob DHCP, DNS, SSH, SMB, NFS, Squid, IMAP etc. mindestens eine konfigurierte Netzwerkschnittstelle.

Bei einem Client ist es möglich, abzufragen, ob ein Netzwerkkabel gesteckt oder abgesteckt wurde, z.B. mit allow-hotplug in der /etc/network/interfaces. Ähnliches gilt für WLAN, wenn man den Empfangsbereich verläßt oder in einen neuen Empfangsbereich kommt. Die Situation ist hier aber eine andere. Da wird auf die unkonfigurierte Netzwerkschnittstelle reagiert, um sie daraufhin zu konfigurieren.
In der doku steht was von rtnetlink, das ist nicht dafuer gedacht?
Nein, nicht wirklich.
Kann es wirklich viel Rechenzeit kosten jede Sekunde nachzufragen ob ein interface up ist?
Nein, einmal pro Sekunde zu prüfen, kostet so gut wie gar nichts, verlängert aber den Bootvorgang unnötig. Wenn du 30 Dienste startest, die jeweils 1-2 Sekunden warten, bis ihre Randbedingungen erfüllt sind, dann hast du unter Umständen 30-60s zusätzliche Bootzeit.

Läßt man als anderes Extrem gar keine Wartezeit zu, so könnte eine aktuelle CPU damit ausgelastet werden 100 Millionen mal pro Sekunde irgendeinen Zustand abzufragen, die andere Prozesse bekommen dann im zweifelsfall gar keine CPU-Zeit mehr.

Wie gesagt, Polling ist doof. :mrgreen:

Und genau darum gibt es z.B.

Code: Alles auswählen

 After=network.target auditd.service
in der /lib/systemd/system/ssh.service. Systemd sorgt dann dafür, daß SSH erst dann gestartet wird, wenn das Netzwerk und der Auditd laufen. Der Nachteil dieser Hierarchiedefinition ist halt, daß die CPU beim Booten eventuell nicht komplett ausgelastet werden kann, weil für einige Dienste systemd durch das Warten auf die Randbedingungen einige Dienste nicht vollständig parallelisiert starten kann.

Antworten