systemd

[NAB]

Ich habe das Problem immer noch nicht verstanden und sehe im Moment auch keines. Wird mysqld nicht via Service-Unit gestartet, in die man eben "after my-uncrypt-script.sh" eintragen könnte?

Richtig! Und da das Setup in Wirklichkeit noch um einiges komplizierter ist, darf ich zig Units manuell serialisieren! Eh, warte ... da gab's doch was, das das automatisch macht ...

Und wie wanne schon sagte, müssen die Geräte natürlich auch aus der crypttab und der fstab raus, also aus dem, was vorher mal die Systemkonfiguration war. Ich muss sie vor Systemd verstecken.

[TomL]

Ich habe das Problem immer noch nicht verstanden und sehe im Moment auch keines. Wird mysqld nicht via Service-Unit gestartet, in die man eben "after my-uncrypt-script.sh" eintragen könnte?

Richtig! Und da das Setup in Wirklichkeit noch um einiges komplizierter ist, darf ich zig Units manuell serialisieren! Eh, warte ... da gab's doch was, das das automatisch macht ...

sysvinit serialisiert automatisch in korrekter und benötigter Reihenfolge? Man muss bei sysvinit nicht ausdrücklich vorgeben, dass der uncrypt vor mount und mount vor Start mysqld erfolgen muss? Das habe ich aber völlig anders in Erinnerung. Woher kennt sysvinit den richtigen Ablauf, wenn das nicht funktionell analog zu systemd vom Customizer festgelegt worden ist?

Die Serialisierung ist hier m.E. mit dem funktionalen Hintergrund absolut identisch.... andere Methode, gleicher Effekt. Das was Wanne beschrieben hat, scheint dem entgegen ein wirklicher Unterschied zu sein.

Nur kann ich da die Bedeutung und und vor allem die Relevanz als Problem noch nicht einschätzen. Ich kaue nämlich schon die ganze auf der Frage rum, wieso sich ein Dienstestarter überhaupt mit Entschlüsselung zu befassen hat, oder mit der Logik bei irgendwelchen mounts. Irgendwie denke ich da, das ist doch gar nicht seine Aufgabe. Es soll das lokale Filesystem starten, und wenn es andere mounts gibt, solls die eingetragenen Jobs zum richtigen Zeitpunkt starten, die das benötigte tun. Um andere Aufgaben solls sich doch gar kümmern . Ich betrachte eigentlich fast alles aus dieser Perspektive. Es soll zur richtigen Zeit den richtigen Job starten .... alles danach ist Aufgabe des Jobs.

[NAB]

Man muss bei sysvinit nicht ausdrücklich vorgeben, dass der uncrypt vor mount und mount vor Start mysqld erfolgen muss?

Nein, muss man nicht. Man muss bei SysVInit nur angeben, dass vor dem mount noch ein decrypt zu erfolgen hat, wenn man so eine Funktion einbauen möchte. Danach weiß SysVInit wieder alleine weiter. Und erfreulicher Weise muss ich bei Debian nicht mal das ... funktioniert bei mir alles automatisch

Du suchst nach irgendwelchen Dingen, die mit Systemd systematisch auf gar keinen Fall gehen. Die gibt es meiner Meinung nach nicht. Man kriegt es immer irgendwie hingebogen. Es ist nur eine Frage der Arbeit und damit des Geldes ... und der "Features" von Systemd, die dabei auf der Strecke bleiben. Ich kann mir auch Systemd patchen, dass es die crypttab wieder korrekt parsed. Möchte ich aber vorläufig vermeiden. Bei der Entwicklungsgeschwindigkeit und der feindseeligen Einstellung von Poettering kann ich mir die Arbeit dann vermutlich zig mal machen.

Auch der Trick mit der initrd klappt eventuell nur so lange, wie Systemd nicht in die initrd einzieht. Dann müsste man wieder neu drumrumbasteln. Im Podcast auf Seite 1 sagt Poettering, dass er Shellscripte ganz aus dem Bootprozess raus haben möchte.

[TomL]

Im Podcast auf Seite 1 sagt Poettering, dass er Shellscripte ganz aus dem Bootprozess raus haben möchte.

Meint er damit die rc*.d-Links, die auf die Scripte in init.d verweisen? Oder meint er damit Shellscripte generell? Also die Runlevel-Scripte halte ich auch für entbehrlich (eigentlich sogar für überflüssig), aber ganz ohne Scripte kann ich mir nicht vorstellen. Deswegen die Frage, was meint er wirklich?

Ich bin der Meinung (laienhaft umschrieben), dass müsste sich so in Richtung "objektorientierter Kapselung" bewegen: ein Job erledigt eine Aufgabe und wird dabei zur passenden Zeit vom Dienstestarter aufgerufen. Der Dienstestarter überwacht nicht, was der Job tut und kümmert sich auch nicht darum, ob er das kann und was er dazu braucht, sondern wartet nur, dass er fertig meldet. Der Starter achtet als Diensteverwaltung nur darauf, dass nix tot übern Zaun hängt, auf evtl. Timeouts und das nicht irgendein Job was blockieren darf, wenn irgendwo was anderes klemmt. Die in den Jobs benötigte Logik liegt nie beim Starter, sondern immer bei den Jobs. Ich glaube, Wayland löst das so ähnlich, wenn ich dessen Konzept richtig verstanden habe.... die Clients kümmern sich selber um das, was auf den Bildschirm kommt und nicht mehr wie traditionell, der xserver.

Ich glaube, dass das der richtige Weg ist.... weg von den eierlegendenwollmilchsäuen, hin zur dezentralen Verantwortung.... lediglich ein starker zentraler Manager, der sich pauschal (und ohne Detailwissen) um Abläufe, Timing usw. kümmert. Keine Ahnung, ob meine Betrachtung was mit der Realität zu tun hat.... aber zumindest mir erscheint das mit meinen früheren Erfahrungen sinnvoll.

[NAB]

Deswegen die Frage, was meint er wirklich?

Weiß nicht! Und selbst wenn er was meint, kann er morgen schon wieder was anderes meinen. Er hat ja kein fertiges Konzept, das er implementiert, sondern expandiert immer mehr. Lass dich halt überraschen

[wanne]

sysvinit serialisiert automatisch in korrekter und benötigter Reihenfolge? Man muss bei sysvinit nicht ausdrücklich vorgeben, dass der uncrypt vor mount und mount vor Start mysqld erfolgen muss? Das habe ich aber völlig anders in Erinnerung. Woher kennt sysvinit den richtigen Ablauf, wenn das nicht funktionell analog zu systemd vom Customizer festgelegt worden ist?

So einfach ist es nicht. System V init konnte das nicht. Aber im LSB stand drin, dass in den init-scripte (analog zu Systemd) Provides:, Required-Start: und Required-Stop: definiert ist. Damit konnten Dritttools (unter debian service.) automatisch Serialisieren.
Die großen Unterschiede:

• Be SystemV init wurde die Reihenfolge ein mal beim installieren eines neuen Services festgelegt. Danach bootet SystemV init immer in der Reihenfolge. Systemd macht das bei jedem boot dynamisch neu.
• Systemd kann wohl auch zwischenstates: Ich kann sagen ich brauche gar nicht warten bis das Netzwerk vollständig da ist (also ich eine IP habe). Für avahi reicht mir, wenn die Interfaces da sind.
• Parallelisierung war in SystemV init nie wirklich vorgesehen. Moderne starten einfach alles parallel wo die Reihenfolge nicht weiter spezifiziert ist. (Was nicht vollständig Standardkonform ist. Es könnte rein theoretisch Wurst sein in welcher Reihenfolge ein Dienst gestartet wird aber wohl dass es nacheinander passiert. (Siehe Kohärenz und Dining philosophers) Weiß aber auch nicht ob Systemd sowas abbilden könnte.)
• Da SystemV init zur Serialisierungszeit nichts über Timings weiß, kannst du Abhängigkeitsbäume nicht abbilden. Nur queues. Hast du die Abhängigkeiten a<b; a<c und c<d bildet das SystemV auf a<b^c<d ab. => b<d (Was so keine Vorgabe war.) Braucht ein parallel gestarteter Dienst (b) also wesentlich länger als der andere (c) hällt er das ganze System (u.u. unnötig) auf.

Ich betrachte eigentlich fast alles aus dieser Perspektive. Es soll zur richtigen Zeit den richtigen Job starten .... alles danach ist Aufgabe des Jobs.

Das ist eben der Teil der sehr gut an Systemd funktioniert. (Auch wenn ich vorher auch da ein Haar in der Suppe finden konnte.) Das wirkliche Problem, ist dass was Systemd eben jetzt auch noch macht. Mit dem logging sind sehr viele Leute sehr unglücklich. Ich habe sehr große Probleme mit dem Device Management gehabt. Die meisten Entwickler beschweren sich über das Sessionmanagement...
Deswegen kommen eben alle mit der UNIX-Philosophie: Solange alles gut tut ist man mit Eierlegenden Wollmilchsäuen wie ssh sehr zufrieden. Aber Systemd macht eben eine Aufgabe gut (Servicemanagement.) und sehr viele schlecht. Deswegen auch so Projekte wie uselessd: http://uselessd.darknedgy.net/

Ich glaube, dass das der richtige Weg ist.... weg von den eierlegendenwollmilchsäuen, hin zur dezentralen Verantwortung.... lediglich ein starker zentraler Manager, der sich pauschal (und ohne Detailwissen) um Abläufe, Timing usw. kümmert.

Das Ding gab's schon: Nannte sich SystemV init.

[heisenberg]

Der Thread war mir stellenweise viel zu kompliziert. Mal schauen vielleicht werde ich das bei Gelegenheit nochmal genauer lesen. In der Zwischenzeit habe ich mir meine eigenen Überlegungen gemacht und bisherige eigene Einstellungen überprüft:

• Schnell Booten Wenn ich mir das genau überlege, dann ist das nicht wesentlich. 5-10 Sekunden hin oder her sind mir dann doch egal.
• Blockierende Dienste Wenn Dienste blockieren( z. B. wg. nicht erreichbarer DNS- Server weil die Netzwerkkonfig einen Schuss hat,...) ist das schon lästiger und das booten dann halt mal 5 Minuten dauert, aber auch das ist nicht der Showstopper.
• Diensteverwaltung Das ist wirklich etwas was ich haben will und was einfach gehen sollte und zuverlässig obendrein: Starten, Beenden, Aktivieren, Deaktivieren, Status abfragen. Immer wieder gab's überkomplizierte, grotttige oder nicht funktionierende Init-Scripte. Damit meine ich jetzt vor allem Drittanbieter Scripte, nicht die von Debian mitgelieferten, die sind/waren nur mässig nervig.
• Diensteeinrichtung Auch das fand ich bisher immer hässlich und nervend. Die Unit-Files haben das sehr einfach gemacht und da will ich auch gerne noch viele Features haben, auf die ich bei Bedarf zurückgreifen kann, ohne mir das selber jedes Mal neu zusammenstümpern zu müssen.
• Logging Ja, auch das Logging finde ich wesentlich besser gelöst mit systemd. In erster Linie sind das die log-Selektoren nach Dienst. Will man deswegen binäre Logs haben? Eher nicht.

Solange alles gut tut ist man mit Eierlegenden Wollmilchsäuen ... sehr zufrieden.

Das sehe ich genauso. systemd ist unten drunter schon ein komplexes Monster. Bis jetzt hatte ich noch nie ein Problem damit - glücklicherweise und es war mir eigentlich egal. Doch wenn ich jetzt darüber nachdenke. Was mir fehlte war das Servicemanagement und nicht mehr.

Auch wenn systemd vielleicht nicht das ist, wie man es haben will - es hat das, was lange dringend nötig war(siehe Liste) und nicht zufriedenstellend gelöst war endlich mal umgesetzt.

[ingo2]

So, hatte ich versprochen, mein Ergebnis hier zu posten:

Der Tipp von TomL hat tatsächlich geholfen. Ausführen von "umountnfs.sh" vorm Shutdown/Reboot beseitigt bei mir die Hänger von 90s für den Timeout von systemd. Habe es jetzt zig Mal probiert - immer ohne nennenswerte Verzögerungen.

Das ist zwar eigentlich nur ein Würgeround für - ich sag's mal provokativ - "die Leseschwäche von systemd". Denn alle 7 Einträge zu nfs-Mountpoins in der fstab bei mir haben den Parameter "noauto", sollten systemd also nichts angehen. Ok, die Mount-Ziele liegen auf Devices, die nicht unbedingt alle immer erreichbar sind, können auch mal während einer Session auftauchen oder verschwinden. Und einen nfs-Mount hänge ich immer manuell vor einem Shutdown aus.

Und für andere geplagte User mit gleichem Problem und XFCE-Desktop hier noch das vollständige Kochrezept:

Zwei *.desktop Files erstellen:

~/.local/share/applications/reboot.desktop

Code: Alles auswählen

[Desktop Entry]
Version=1.0
Type=Application
Name=Reboot
Comment=Helper for Umount NFS-Shares before reboot
Exec=/bin/bash -c "sudo /etc/init.d/umountnfs.sh && xfce4-session-logout --reboot"
Icon=/usr/share/icons/Tango/scalable/actions/reload.svg
Terminal=true
Path=
StartupNotify=false

~/.local/share/applications/shutdown.desktop

Code: Alles auswählen

[Desktop Entry]
Version=1.0
Type=Application
Name=Shutdown
Comment=Helper for Umount NFS-Shares before shutdown
Exec=/bin/bash -c "sudo /etc/init.d/umountnfs.sh && xfce4-session-logout --halt"
Icon=process-stop
Path=
Terminal=true
StartupNotify=false

und die jeweils auf einen Starter im Panel legen für Shutdown und Reboot. Anstelle des üblichen me-menus benutzen.

Jetzt noch das Ausführen von "umountnfs.sh" für den User ohne Passwort erlauben:

nano /etc/sudoers
und folgende Zeile einfügen

Code: Alles auswählen

<username>    ALL=(ALL)NOPASSWD:/etc/init.d/umountnfs.sh

Das war's schon und so bleibt es bei mir!

P.S.: Eigentlich sollte man die Lösung irgendwie im Titel kenntlich machen, aber wie das aussagekräftig bei diesem bunten Theread und auch noch unter Smalltalk gehen soll - keine Ahnung. Vielleicht ein Link im entsprechenden Forum???

Beste Grüße,
Ingo

EDIT: Den Hänger beim folgenden Boot, den ich ganz am Anfang 1x hatte, gab's nie wieder. Ich führe den auf den radikalen Shutdown mit "poweroff" aus der laufenden Desktop-Session heraus zurück (tritt also mit "xfce4-session-logout" nicht mehr auf).

[ingo2]

So, noch ein letztes Mal:

Seither nie mehr ein Hänger beim Shutdown - "umountnfs.sh" war wohl der entscheidende Tipp, s.o..

Ich markiere den Thread daher mal als [shutdown gelöst],
Ingo

[ralli]

Im Netz gefunden:

https://www.agwa.name/blog/post/how_to_ ... _one_tweet

Aber nicht ausprobieren, gell?

[ingo2]

Aber nicht ausprobieren, gell?

Nee, mache ich auch nicht, passiert offenbar unter Jessie von Zeit zu Zeit immer noch der 90s Timeout beim Shutdown

Aber Spass bei Seite.
Unter Stretch dauert der gesamte Shutdown seit einiger Zeit konstant fast 20s. Dabei wird dann im Terminal auisgegeben "deconfiguring network interface" wohl per ifup und/oder ifdown. Das dann 2x für eth0 und wlan0 - dauert zusammen alleine 15 Sec.

Da ist Wheezy deutlich schneller im Shutdown!

[Radfahrer]

Bei mir dauert der shutdown unter Stretch etwa zwei Sekunden.

[ingo2]

Bei mir dauert der shutdown unter Stretch etwa zwei Sekunden.

Wie hast du denn deine Netzwerk-Interfaces konfiguriert?

Bei mir über die /etc/network/interfaces:

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet static
	address 192.168.xy.12
	netmask 255.255.255.0
	network 192.168.xy.0
	broadcast 192.168.xy.255
	gateway 192.168.xy.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 192.168.xy.1
	dns-search home

Und der WLAN-Adapter ebenso:

Code: Alles auswählen

# WLAN mit fester Adresse für hostapd
allow-hotplug wlan0
	iface wlan0 inet static
	address 10.0.0.1
	netmask 255.255.255.0
	broadcast 10.0.0.255

# Firewall zurücksetzen, Tabellen leeren
	up /sbin/iptables -F
	up /sbin/iptables -X
	up /sbin/iptables -t nat -F

# Kabelnetzwerk maskieren, Port-Forwarding sowie Nat aktivieren
	up iptables -A FORWARD -o eth0 -i wlan0 -s 192.168.xy.0/24 -m conntrack --ctstate NEW -j ACCEPT
	up iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
	up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
	up sysctl -w net.ipv4.ip_forward=1

# hostapd und dnsmasq (neu) starten
	up service hostapd restart
	up service dnsmasq restart

[Radfahrer]

Ich benutze schlicht und einfach den network-manager-gnome.
IPs werden über DHCP bezogen, allerdings ist der Router so eingestellt, dass er meinen Rechnern immer die gleichen IPs gibt.

[ingo2]

So, habe jetzt mal eth0 auf dhcp konfiguriert:

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet static

Dann ist der Delay beim Shutdon zwar weg, aber:
ich bekomme nur noch IPv6-Verbindungen nach extern, IPv4 ist nur intern möglich.
Und das, obwohl ein "ifconfig" sagt, eth0 hat eine IPv4-Adresse und ein Gateway. Auch die /etc/resolv.conf ist ok - es geht nur nicht

[ingo2]

So, habe jetzt mal eth0 auf dhcp konfiguriert:

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet dhcp

Dann ist der Delay beim Shutdon zwar weg, aber:
ich bekomme nur noch IPv6-Verbindungen nach extern, IPv4 ist nur intern möglich.
Und das, obwohl ein "ifconfig" sagt, eth0 hat eine IPv4-Adresse und ein Gateway. Auch die /etc/resolv.conf ist ok - es geht nur nicht

[ingo2]

Problem erkannt:
bei irgendeiner Aktion in der letzten Zeit hat es mir offenbar den network-manager ungewollt auf die Platte gespült. Der hat da nix zu suchen, macht, wie man sieht, nur Ärger
und gelöst:

Code: Alles auswählen

apt-get purge network-manager

Jetzt geht auch der Shutdown wieder wie gehabt in 2 Sekunden!

[Radfahrer]

Der macht nur Schwierigkeiten, wenn man nicht weiß, dass er eine eigene config hat.
Die /network/interfaces macht dann Ärger.

https://wiki.ubuntuusers.de/interfaces/