systemd

[catdog2]

Nunja, niemand fragte, wo da das Problem liegt. Das weiß ich auch nicht. SysVInit drauf und gut

Aber es verletzt halt religiöse Gefühle, wenn aus $Grund noch irgendein Paket installiert sein muss welches systemd im Namen trägt.

Und du willst wissen, wie es zu diesem "geht nicht" kommt. Soweit ich das verstanden habe, möchte Poettering, dass die Leute ihre Keyscripts zukünftig in C schreiben, weil C viel einfacher ist als Bash.

Wo willst du das raus lesen? Zumindest in dem vorhin verlinkten Ding steht das nicht.
Er hat glaub ich nicht wirklich Lust auf Extrawürste für die Bash, das mag sein. Hindert aber keinen daran eine "richtige" Skriptsprache anstatt einer Shell [1] zu nehmen. Alternativ kann man sicherlich auch einen Helfer schreiben, der das für Shellskriptliebhaber angenehm verwendbar macht.

[1] Ich will damit in keinster weise Shells schlecht machen. Shells sind klar darauf spezialisiert eine Benutzerschnittstelle zu sein, das können sie gut, andere Dinge halt nicht so gut.

[NAB]

Aber es verletzt halt religiöse Gefühle, wenn aus $Grund noch irgendein Paket installiert sein muss welches systemd im Namen trägt.

Na, wenn's bei dir so schlimm ist, dann ist es doch sicherlich möglich, das Paket umzubenennen.

Wo willst du das raus lesen? Zumindest in dem vorhin verlinkten Ding steht das nicht.
Er hat glaub ich nicht wirklich Lust auf Extrawürste für die Bash, das mag sein. Hindert aber keinen daran eine "richtige" Skriptsprache anstatt einer Shell [1] zu nehmen. Alternativ kann man sicherlich auch einen Helfer schreiben, der das für Shellskriptliebhaber angenehm verwendbar macht.

Dass Poettering Shellscripte zu kompliziert findet, sagt er in dem von Lord Carlos auf Seite 1 verlinkten Podcast und dass er eine C-Implementierung bevorzugt, schließe ich aus der von Lord Carlos verlinkten Mail auf [systemd-devel] auf der vorherigen Seite. Wobei ich mir nicht ganz sicher bin, was der "Marc Haber" da (in der initrd?) wie erreichen will und somit nicht weiß, ob der Zusammenhang stimmt. Wenn du genaueres darüber weißt, ob und wie eine Implementierung möglich ist, dann immer her damit, am besten in den zugehörigen Bugreport.

[Lord_Carlos]

SystemD ist alternativlos.

[DeletedUserReAsG]

Warum versuchst du zu trollen?

[Lord_Carlos]

Warum versuchst du zu trollen?

Damit der "Bitte meinen Account löschen!" Thread wieder in schwung kommt.

[MSfree]

Dass Poettering Shellscripte zu kompliziert findet

Ich denke, diese Aussage ist aus dem Zusammenhang gerissen und wäre eines Informatikers auch überhaupt nicht würdig. Vor allem widerspricht dies der Verkomplizierung durch systemd ansich.

Die Start-Stop-Skripte in SysV-init sind im Laufe der letzten 20 Jahre immer komplizierter geworden, um immer mehr Fälle abdecken zu können. Man hat z.B. Teile der Skriptsteuerung in Parameter unter /etc/default verlagert, obwohl die meisten Daemons eine Konfigurationsdatei mitbringen, in der die gleichen Parameter eingestellt werden könnten. Vermutlich ist aber das Parsen solcher Konfigurationsdateien mit dpkg-reconfigure nicht möglich, so daß man auf externe Parameter ausgewichen ist.

In fast allen Fällen hätten die Maintainer aber eine extreme Entschlackung dieser Skripte vornehmen können. Ich habe mal einige Skripte um 90% entschlackt ohne Funktionalität zu verlieren. Poettering hat also zumindest teilweise Recht.

und dass er eine C-Implementierung bevorzugt

Er bevorzugt den direkten Start von Daemons und Programmen statt sie durch Skripte starten zu lassen. Dabei erspart man sich eine Indirektion, was letztlich auch der Geschwindigkeit dient. Wobei der Geschwindigkeitsvorteil homöopatisch ist, weil der Start eine Shellinterpreters praktisch keine Zeit kostet, der Kernel cached da ziemlich effektiv. Vor allem aber wird der Start von Daemons über ein Skript auch in systemd durch die Auslagerung von Parametern in /etc/default nötig, so daß man hier eigentlich nichts gewinnt.

Ein anderes Beispiel für Skripte ist, wenn ich eine Reihe Filterregeln für iptables erstellen will. Dann kann ich das für mich am übersichtlichsten in einem Skript machen. Ich kann mich natürlich auch iptable-save und iptable-restore bedienen und die Regeln in dem Syntax dieser beiden Programme erstellen. Ich finde das allerdings wenig übersichtlich und für meine Fälle unpraktikabel.

Und welche Skriptsprache man dabei verwendet, sollte Herr Poettering doch bitte anderen überlassen. Er hat schon genug diktatorische Vorgaben mit systemd gemacht, die nicht nur mir sehr sauer aufstossen.

[catdog2]

Und welche Skriptsprache man dabei verwendet, sollte Herr Poettering doch bitte anderen überlassen. Er hat schon genug diktatorische Vorgaben mit systemd gemacht, die nicht nur mir sehr sauer aufstossen.

Gähn. Bringt doch mal was neues, wird ja noch langweilig hier.

[TomL]

Moin

Ich kann doch in der initrd starten, wonach mir gerade ist – und wenn mir gerade nach ’nem kurzen Script ist, das schaut, ob ein bestimmter Stick steckt und ggf. eine Datei oder einen Bereich davon hernimmt, um den Systemdatenträger damit zu entschlüsseln, dann starte ich das halt dort?

Ich habe jetzt fast zwei Tage mit Suchen im Web verbracht, um das zu verstehen. Leider erfolglos. Worin besteht der Unterschied, wenn ich das gleiche Script via initrd oder systemd starte? Mir ist als einziger relevanter Unterschied der Zeitpunkt in den Sinn gekommen, das ein initrd-Script möglicherweise noch vor Systemd gestartet werden kann. Aber die Notwendigkeit scheint ja gar nicht zu bestehen, wenn bemängelt wird, dass systemd das nur wg. der key-scripts nicht kann.... also ist der spätere Zeitpunkt in Systemd ja anscheinend nicht das Problem. Und das ein initrd-Script "mehr" kann... ?... der Gedanke kommt mir momentan absurd vor.

[DeletedUserReAsG]

Und welche Skriptsprache man dabei verwendet, sollte Herr Poettering doch bitte anderen überlassen.

Und … an welcher Stelle schreibt er dir vor, dass die erste Zeile im via systemd zu startenden Script nicht ›#! /bin/bash‹ sein darf?

Mir ist als einziger relevanter Unterschied der Zeitpunkt in den Sinn gekommen, das ein initrd-Script möglicherweise noch vor Systemd gestartet werden kann.

An der Stelle kommt systemd noch nicht zum Tragen. Es gibt Sachen, die lassen sich manuell besser/sicherer erledigen, und das Freischalten/Einhängen verschlüsselter (System-)Devices vor dem eigentlichen System[d]start ist, meiner Meinung nach, eine davon. Insbesondere halte ich das für sinnvoll, wenn systemd selbst auf dem verschlüsselten Device residiert ….

@Lord_Carlos: „Der Carl trollt im systemd-Thread, bitte löscht meinen Account!!k“ – oder was schwebt dir vor? Ich befürchte, da überschätzt du deine Relevanz

[MSfree]

Und … an welcher Stelle schreibt er dir vor, dass die erste Zeile im via systemd zu startenden Script nicht ›#! /bin/bash‹ sein darf?

Habe ich geschrieben, daß er mir hier etwas vorschreibt?

Es steht aber zu befürchten, daß früher oder später systemd die erste Zeile der Skripte analysiert und alle Skriptsprachen, die nicht "systemd-konform" sind, verweigert. Vor allem wird das dann nicht bash sein sondern eine "viel einfachere" Skriptsprache wie Python oder Perl.

[DeletedUserReAsG]

Es steht aber zu befürchten, daß früher oder später systemd die erste Zeile der Skripte analysiert und alle Skriptsprachen, die nicht "systemd-konform" sind, verweigert.

Gibt es dafür konkrete Hinweise? Ich kann mir nicht vorstellen, dass systemd irgendwas analysiert und daraufhin entscheidet, ob es das startet oder nicht. Wenn es ausführbar ist (und im Idealfall noch ’nen korrekten Rückgabewert liefert), wird’s gestartet – das ist der derzeitige Stand bei allen mir bislang bekannten Initsystemen.

[TomL]

An der Stelle kommt systemd noch nicht zum Tragen. Es gibt Sachen, die lassen sich manuell besser/sicherer erledigen, und das Freischalten/Einhängen verschlüsselter (System-)Devices vor dem eigentlichen System[d]start ist, meiner Meinung nach, eine davon. Insbesondere halte ich das für sinnvoll, wenn systemd selbst auf dem verschlüsselten Device residiert ….

Ja, das ist das, was ich mir mit etwas drüber nachdenken auch gedacht habe.... wenn Teile des Betriebssystems selber auf einer verschlüsselten Partition liegen, gehts ja auch gar nicht anders, als zum frühestmöglichen Zeitpunkt eben über initrd.

Aber im konkreten Beispiel wurde ja bemängelt, dass systemd mit den keyscripts nicht klar kommt. Ich würde jetzt annehmen, da das OS und systemd also schon gestartet sind, handelt es sich vielleicht nur um eine verschlüsselte Datenpartition, deren Entschlüsselung wg. der fehlenden keyscript-Unterstützung mit systemd fehlschlägt. Der Knackpunkt ist, weil systemd sich anscheinend drum kümmern soll, scheint ja ein möglichst früher Zeitpunkt (vor OS) nicht sooo relevant zu sein, es scheitert an diesem späteren Zeitpunkt anscheinend nur wg. der Keyscripts. Gibt es also noch andere Unterschiede zwischen dem initrd-Script und dem gleichen etwas später von systemd gestarteten? Ich kann doch auch von systemd ein beliebiges Script starten lassen, was mal eben nach 'nem bestimmten USB-Stick schaut und dann darüber eine solche "sekundäre" Partition entschlüsselt.

Mich interessiert, ob dieser angebliche Mangel überhaupt ein wirklicher Mangel ist.

[NAB]

Ich kann doch auch von systemd ein beliebiges Script starten lassen, was mal eben nach 'nem bestimmten USB-Stick schaut und dann darüber eine solche "sekundäre" Partition entschlüsselt.

Das musst du aber machen, bevor Systemd mysqld startet! Auf dieser Partition liegt nämlich deine Kundendatenbank!

[wanne]

Und … an welcher Stelle schreibt er dir vor, dass die erste Zeile im via systemd zu startenden Script nicht ›#! /bin/bash‹ sein darf?

Zuerstmal: Das wird insbesondere in Debian genutzt. Du kannst sogar soweit gehen und einfach das alte SysV-init als eigenen systemd-Dienst zu starten.
Es wird aber an vielen stellen ausdrücklich angemerkt, dass man das nicht so machen soll. Außerdem zerschießt man sich damit die status und reload Optionen.

Ich kann doch auch von systemd ein beliebiges Script starten lassen, was mal eben nach 'nem bestimmten USB-Stick schaut und dann darüber eine solche "sekundäre" Partition entschlüsselt.

Das Problem ist ein anderes: Systemd interpretiert die konfigurationsdateien von cryptsetup und mount (namentlich die fstab und crypttab). Schreibe ich da die Konfiguration für die verschlüsselte Partition rein fliegt Systemd auf die Schnauze und kann nicht mehr booten. Schreibe ich sie nicht rein, funktioniert cryptsetup nicht mehr. Das ist besonders ärgerlich, da Systemd ja zusätzlich eigene Konfigurationsdateien hat. Es gab keinen Grund dafür trotzdem zusätzlich die alten configs auch zu interpretieren. (D.h. der einzige Grund war einen Vollumfänglichen Wechsel zu Systemd zu erzwingen, auch wenn der Nutzer das nicht will. )
Für / und swap geht das noch weiter. Früher konnte ich (dank initrd) eben auch ohne / booten. Systemd will das jetzt als parameter und kann deswegen eben nicht mehr starten, wenn es / nicht öffnen kann. Swaps werden sogar vollständig ungefragt genutzt und überschrieben.

[TomL]

Das musst du aber machen, bevor Systemd mysqld startet! Auf dieser Partition liegt nämlich deine Kundendatenbank!

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?

@Wanne
Das muss ich jetzt erst mal sacken lassen ... und drüber nachdenken.

[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?