Systemd und dm over dm

[wanne]

Hier ein Ausschnit aus lsblk:

Code: Alles auswählen

└─sda8           8:8    0    80G  0 part  
  └─ext_cache  254:4    0 217.7G  0 dm    
    └─ext_home 254:5    0 217.7G  0 crypt /home/wanne/VirtualBox VMs

Das Problem ist ich habe einen dm-crypt (ext_home) in einem dm-cache (ext_cache).
Entsprechen muss beim runterfahren zuerst /home/wanne/VirtualBox VMs ungemounted werden dann ext_home geschlossen werden und dann ext_cache geschlossen.
Im Moment wird aber zuerst der ext_cache geschlossen dann versucht er zu unmounted und bleibt dran hängen, weil er die gecachten Daten nicht mehr zurückschreiben kann. Das ist ziemlich sch*

Mein Unit-File sieht so aus:

Code: Alles auswählen

[Unit]
Description=Cache-device for ext_home
RequiredBy=systemd-cryptsetup@ext_home.service
Before=cryptsetup.target local-fs.target cryptsetup@ext_home.service

Das hilft aber irgend wie nichts. Sie wird trotzdem VOR systemd-cryptsetup@ext_home.service gestoppt.

Btw: War der Grund für systemd nicht, dass es das Abhängkeitsmanagement besser in den griff bekommt?
Unter System V init hat das getan.

[TomL]

Wo sind denn die Abhängigkeiten der mounts und in folgedessen die Reihenfolge der umounts beim Shutdown definiert? Und wo ist die Abhängigkeit der dm-Devices zu diesen Mounts definiert? So, wie es jetzt auf mich wirkt, behandelt systemd das völlig ohne Abhängigkeiten.... und deswegen die Probleme.

[wanne]

Siehe:

Code: Alles auswählen

RequiredBy=systemd-cryptsetup@ext_home.service

Da sollte das Ding eigentlich nicht vor ext_home beendet werden.

[rendegast]

So, wie es jetzt auf mich wirkt, behandelt systemd das völlig ohne Abhängigkeiten.... und deswegen die Probleme.

Das hieße, daß irgendwo der default DefaultDependencies=yes ( implizit? ) außer Kraft gesetzt würde,
der dafür sorgt, daß ein Requires=/RequiredBy= automatisch mit einem Before=/After= verbunden wird.
Und stattdessen ein lockereres "Starten/Beenden mit" gilt.
Oder es spielen weitere, eventuell implizite Before=/After= mit hinein.
(Sowas ist unter sysv/insserv leichter zu debuggen)

Code: Alles auswählen

systemctl list-dependencies ....

?


(Den in interaktiver Shell farbig dargestellten Status (1. Spalte) der dependency in einer Pipe erhalten:

Code: Alles auswählen

script -q -c '[systemctl|journalctl] --no-pager  ...  ...'   |   ...

Jedoch kann gerade diese Ausgabe im RAW-Code sehr unübersichtlich werden.
Zudem wird in dieser Lösung das Terminal beeinträchtigt und benötigt hinterher gegebenenfalls ein oder mehrere 'reset'.)

[TomL]

Das hieße, daß irgendwo der default DefaultDependencies=yes ( implizit? ) außer Kraft gesetzt würde,

Nee, das meinte ich nicht, sondern ich bezog mich allein auf sein Konstrukt. Und da muss ich gestehen, dass ich wegen der ziemlich mageren und imho fragmentierten Infos echte Probleme habe, mir dieses Konstrukt eingebettet in den Boot vorzustellen. Zumal mich der Begriff "cache" im Zusammenhang mit "home" völlig irritiert. Ich habe irgendwie ne total andere Vorstellung von "cache", als das ich da 'ne logische Beziehung zu "home" vermuten würde.

Ich kann aus diesem Schnippsel auch gar nix herauslesen.... was macht diese Unit im Execstart? Wird hier entschlüsselt? Oder gemountet? Was...?...ext_cache? Oder ext_home? Oder beides? Oder alles zusammen, weil noch irgendwelche anderen Einstellungen da reinspielen? Und der Grund, warum die Units instantiiert sind, geht auch nirgends draus hervor. Welchen Sinn hat das, wenn es sich um permanente oder physische Devices handelt?

Code: Alles auswählen

[Unit]
Description=Cache-device for ext_home
RequiredBy=systemd-cryptsetup@ext_home.service
Before=cryptsetup.target local-fs.target cryptsetup@ext_home.service

Deshalb kann ich jetzt hier nur gefühlsmäßig an das Problem rangehen. Und da wüde ich von vornherein ein anderen Weg beschreiten. Wenn ich jetzt annehme, dass es zwei Units gibt, einmal für "cache", einmal für "home", würde "cache" bei mir so aussehen:

Code: Alles auswählen

[Unit]
Description=Cache-device for ext_cache
after=local-fs.target

"home" würde so aussehen:

Code: Alles auswählen

[Unit]
Description=Cache-device for ext_home
Requires=cache_name_unbekannt.service
affter=cache_name_unbekannt.service 

Warum "RequiredBy=systemd-cryptsetup@ext_home.service" raus? Weil ich den linearen Weg bevorzuge, also die Abhängigkeit an der Stelle positioniert, wo genau dieser Zustand eine Bedeutung hat. Deswegen der "Requires=" in der home-unit.

Warum "cryptsetup.target" raus? Weil das hier "A target that pulls in setup services for all encrypted block devices." meiner Meinung nach bedeutet, dass ich das komplette Cryptsetup via systemd eingestellt habe. Aber das kann ich hier an dem Codeschnippsel eben nicht herauslesen.

Warum "after=local-fs.target"? Weil imho zur Entschlüsselung einer nachgeschalteten Partition das lokale Filesystem etabliert sein sollte. Ein Crypt-Homedevice ist imho allenfalls für das multiuser.target relevant, also würde ich mit dem cryptsetup erst nach local-fs.target beginnen.

Also, wie gesagt, das ist jetzt alles auch ein bisschen spökenkiekerei.... aber ohne einen Blick auf das gesamte Konstrukt ist mir da kaum mehr möglich.

[wanne]

Code: Alles auswählen

systemctl list-dependencies ....

pastebin.php?mode=view&s=39742

Begriff "cache" im Zusammenhang mit "home" völlig irritiert.

Na ein Cache cached.
Und home_cache cached Daten in /home, damit z.B. die VMs die da liegen schneller hochkommen.
Finde ich nicht so schwer verständlich.
(Um genau zu sein Cached es daten aus dem Crypto device in dem teile von /home liegen.)

was macht diese Unit im Execstart?

Das Caching-Device erstellen.

Code: Alles auswählen

ExecStart=/sbin/dmsetup create ext_cache --table '0 456534016 cache /dev/sda7 /dev/sda8 /dev/sdb4 2048 1 writeback default 0'

Wird hier entschlüsselt? Oder gemountet?

Nein. Das device erstellt, das entschlüsselt werden soll. Deswegen eben RequiredBy=systemd-cryptsetup@ext_home.service

Welchen Sinn hat das, wenn es sich um permanente oder physische Devices handelt?

Die Hardware mag permanent da sein. Die Konfiguration, damit daraus ein device (unter /dev) wird, muss beim Systemstart gemacht werden. (Und vor allem sollte vor dem Runterfahren zurückgeschrieben werden.) Das macht der Unit-File

Ansonsten dachte ich die lsblk-Zeichnung wäre ganz deutlich gewesen. Aber jetzt nochmal in Text:
ext_cache ist ein caching Device, das von der unit ext_cache.service
erstellt wird und direkt auf der Hardware liegt.
In ext_cache liegt ext_home crypto device, das aus in der /etc/crypttab konfiguriert ist.
In ext_home liegen dann diverse Subvolumes, die wiederum in der /etc/fstab (auf die ich nur ungern zu gunsten von Unit-Files verzichten würde) konfiguriert sind.

Es gibt entsprechend nur ein Unit-File und eine Hardware. Aber mehr Devices: ext_cache(ext_home(/home/live/,home/VirtualBoxVMs,…)))
Und die müssen von außen nach innen gestartet werden und von innen nach außen beendet.

Weil ich den linearen Weg bevorzuge, also die Abhängigkeit an der Stelle positioniert, wo genau dieser Zustand eine Bedeutung hat.

Würde ich ja auch bevorzugen. Aber cryptsetup@ext_home.service ist keine "echte" Unit, sondern der hart in systemd einkompilierte cryptsetup-service. Und ich hab wenig Lust an systemd rumzupatchen.

[wanne]

meiner Meinung nach bedeutet, dass ich das komplette Cryptsetup via systemd eingestellt habe.

Das ist mit systemd weitestgehend nicht mehr anders möglich. Wollte man cryptdisk nutzen, müsste man die syntax für cryptsetup in die /etc/crypttab schreiben. Die versteht dann aber systemd nicht, was ihm beim booten das Genick bricht und abstellen, dass systemd die crypttab interpretiert ist meines Wissens nicht möglich.

Warum "after=local-fs.target"?

Da steht Before und das war so ziemlich die letzte Verzweiflungstat, um das Ding auch wirklich als erstes zu starten.

[TomL]

Moin

Sorry, ich klink mich hier aus... damit bin ich überfordert....

meiner Meinung nach bedeutet, dass ich das komplette Cryptsetup via systemd eingestellt habe.

Das ist mit systemd weitestgehend nicht mehr anders möglich. Wollte man cryptdisk nutzen, müsste man die syntax für cryptsetup in die /etc/crypttab schreiben. Die versteht dann aber systemd nicht, was ihm beim booten das Genick bricht und abstellen, dass systemd die crypttab interpretiert ist meines Wissens nicht möglich.

... weil ich der Meinung bin, wenn es sich prinzipiell um physische Devices handelt, die fest installiert sind, nur halt eben verschlüsselt, das man den ganzen Kram mit Crypttab und Systemd eben nicht braucht. Wenn ich alternativ das verschlüsselte Device auch manuell zur Laufzeit des Rechners via Terminal und mit einzelnen Kommandos entschlüssen und mounten könnte, ist das Problem imho gelöst. Dann nehme ich einfach diese Kommandos und pack sie alle in eine Unit. Dann positioniere ich diese Unit an eine Stelle, wo es garantiert funktioniert, eben "after=local-fs.target" und kann mich drauf verlassen, dass es immer klappt und das das Device entschlüsselt vorliegt, wenn multi-user.target angezogen wird. Aber wenn das nicht geht, bin ich mit meinem Latein am Ende.

Da steht Before und das war so ziemlich die letzte Verzweiflungstat, um das Ding auch wirklich als erstes zu starten.

Genau da war ich der Meinung, dass "before" falsch ist, deswegen habe ich das auf "after" geändert. Nach "local-fs.target" beim Boot bedeutet aber auch vor local-fs.target beim Shutdown... und das ist erst mal richtig, damit der Shutdown mir nicht das Filesystem unterm Hintern wegzieht, bevor ich das Cryptdevice sauber geschlossen habe. Und dann muss ich nur noch die Reihenfolge in meinen Units definieren.... da bin ich der Meinung, dass das mit der Kombination von after und requieres in home.services gesichert ist. Aber es scheint alles viel komplizierter zu sein, als ich mir das auch nur vorstellen kann. Sorry...

[rendegast]

[Unit]
Description=Cache-device for ext_home
RequiredBy=systemd-cryptsetup@ext_home.service
Before=cryptsetup.target local-fs.target cryptsetup@ext_home.service

google: "dm-cache"

kylemanna.com
statt den dm-cache explizit aufzusetzen, ihn per lvmcache resp. lvm realisieren.

Weitere Herangehensweise
Statt den dm-cache ext_cache an cryptsetup.target/local-fs.target zu binden, vielleicht

Code: Alles auswählen

[Unit]
Description=Cache-device for ext_home
# RequiredBy=systemd-cryptsetup@ext_home.service
# Before=cryptsetup.target local-fs.target cryptsetup@ext_home.service
PartOf=local-fs-pre.target

... die wiederum in der /etc/fstab (auf die ich nur ungern zu gunsten von Unit-Files verzichten würde)
...
... ext_cache(ext_home(/home/live/,home/VirtualBoxVMs,…)))

Diese in der fstab mit Option _netdev ausstatten, um sie zu verzögern?
Wobei das wohl problematisch ist, wenn das Netzwerk heruntergefahren/neugestartet wird.

Die mounts im crypto-ext_cache doch einem autofs übergeben.

[wanne]

statt den dm-cache explizit aufzusetzen, ihn per lvmcache resp. lvm realisieren.

LVM kann nicht leisten, was ich will und tut btw. auf einfach nicht vernünftig. Egal was Kyle da irgend wann mal gebloggt hat.

PartOf=local-fs-pre.target

Hab ich jetzt ausprobiert. – hilft nichts.

@TomL: Dass ich dir erklärt bekomme wie unter Linux ein dm-cache funktioniert glaube ich nicht mehr. Irgend wie reden wir da an einander vorbei. Wenn's dich interessiert guck dir mal an wie z.B. ein dm-RAID funktioniert. Das nutzt die gleiche API und relativ oft dokumentiert. Vielleicht erkärt da jemand verständlicher.

Das ist aber völlig irrelevant für die eigentliche Frage:

Ich will halt die Startreihenfolge:
ext_cache.service -> cryptsetup@ext_home.service -> Und dann die mounts aus der fstab.
Entsprechend auch die Herunterfahrreihenfolge:
umount (aus der fstab) -> cryptsetup@ext_home.service -> ext_cache.service


Im Moment funktioniert das fürs hochfahren. Beim Runterfahren passiert aber das
ext_cache.service -> umount (Und das hängt sich dann auf, weil ext_cache schon gestorben ist.)

[TomL]

Ich will halt die Startreihenfolge:
ext_cache.service -> cryptsetup@ext_home.service -> Und dann die mounts aus der fstab.
Entsprechend auch die Herunterfahrreihenfolge:
umount (aus der fstab) -> cryptsetup@ext_home.service -> ext_cache.service

Im Moment funktioniert das fürs hochfahren. Beim Runterfahren passiert aber das
ext_cache.service -> umount (Und das hängt sich dann auf, weil ext_cache schon gestorben ist.)

Es funktioniert genau der Weg, den ich oben schon beschrieben habe:

Cache.Service:

Code: Alles auswählen

[Unit]
after=local-fs.target

Cryptsetup.service

Code: Alles auswählen

[Unit]
Requires=cache.service
after=cache.service 

Und im fstab-Statement (options):

Code: Alles auswählen

x-systemd.requires=Cryptsetup.service

[wanne]

Und im fstab-Statement (options):

Code: Alles auswählen

x-systemd.requires=Cryptsetup.service

Das hatte ich übersehen. Nacher mal ausprobieren. Melde mich später wieder.

[TomL]

Den hier nicht vergessen... das ist wichtig, weil diese Unit die erste der Kette ist und dafür erst mal generell das Filesystem etabliert sein muss:

Cache.Service:

Code: Alles auswählen

[Unit]
after=local-fs.target

[wanne]

Problem bleibt

[TomL]

Poste mal die vollständigen (!) Service-Units.... wenn da zugangsdetails enthalten sind, dann anonymisiert... aber sonst vollständig.

[wanne]

So habe es jetzt hinbekommen. Das problem war, dass das überladen des systemd-cryptsetup services nicht funktioniert hat.
Ich habe jetzt die crypttab ganz weggeworfen, den Service in ext_crypt umbenannt und mit cryptsetup statt crypttdisk geschrieb. (Eigentlich ist das eh die besser Variante, das cryptsetup um einiges mächtiger ist.)

Hier der Volle jetzt funktionierende Aufbau:
/etc/systemd/system/ext_cache.service:

Code: Alles auswählen

Description=Cache-device for ext_home
Requires=local-fs.target


[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=5
ExecStart=/sbin/dmsetup create ext_cache --table '0 456534016 cache /dev/sda7 /dev/sda8 /dev/sdb4 2048 1 writeback default 0' 
ExecStop=/sbin/dmsetup suspend ext_cache ; /sbin/dmsetup clear ext_cache ; /sbin/dmsetup remove ext_cache 

[Install]
WantedBy=multi-user.target

/etc/systemd/system/ext_crypt.service

Code: Alles auswählen

[Unit]
Description=Crypto-device for ext_home
Requires=ext_cache.service
After=ext_cache.service


[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=5
ExecStart=/sbin/cryptsetup open --type luks --key-file /etc/hompw --allow-discards /dev/mapper/ext_cache ext_home 
ExecStop=/sbin/cryptsetup close ext_home
                                                                                                                                     
[Install]                                                                                                                            
WantedBy=multi-user.target

/etc/fstab

Code: Alles auswählen

[…]
LABEL=ext_home          /home/wanne/VirtualBox\040VMs  btrfs nofail,compress=zlib,subvol=/VMs,x-systemd.after=ext_crypt.service        0 0
LABEL=ext_home          /home/live                     btrfs nofail,compress=zlib,subvol=/live,x-systemd.after=ext_crypt.service       0 0

Vielen dank nochmal an TomL für die Mühe.

[schorsch_76]

Nur ein kleiner Hinweis:

Code: Alles auswählen

Requires=local-fs.target

Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird. Deshalb gibt es da das Pattern

Code: Alles auswählen

Requires=local-fs.target
After=local-fs.target

https://www.freedesktop.org/software/sy ... html[quote]
Requires=
Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.
[/quote]

Siehe auch:
http://serverfault.com/questions/812584 ... d-requires

[wanne]

Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird.

Kp. Ich habe das nur eingebaut, weil TomL das gesagt hat.

[wanne]

Von wegen:
Das ganze funktioniert nur, wenn ich nicht als live angemeldet bin.
Bin ich als live angemeldet und fahre dann herunter passiert das:

Code: Alles auswählen

Unmounting /home/live
umount: /home: target is bus
systemd[1]: Stopping Crypto-device for ext_home...
cryptsetup[2503]: device-mapper: remove ioctl on ext_home failed: Device or resource busy
systemd[1]: home.mount mount process exited, code=exited status=32
systemd[1]: Failed unmounting /home.
[…]
systemd[1]: ext_crypt.service: control process exited, code=exited status=5

a) Systemd Versucht weiterhin das device zu removen, obwohl er es nicht selber erstlle.
b) Er versucht /home/live zu unmounten obwohl ich noch eingeloggt bin. Das schlägt fehl. Daraufhin fährt einfach mit der ganz normalen Bootreihenfolge fort.
c) Die x-systemd werden fleisig ignoriert. Er gibt das schlicht und einfach dem mount Befehl mit.

[wanne]

so ich habe jetzt aufgegeben und für jeden mount einen eigenen unit file erstellt.
Das funktioniert. der systemd cryptsetup service versucht immer noch dazwischen zu pfuschen. Faild dann aber zum glück.
Log dazu:

Code: Alles auswählen

cryptsetup[2345]: device-mapper: remove ioctl on ext_home failed: Device or resource busy

Und das obwohl er das Device nie anlegt.

Hier noch ein paar Highlights aus dem log zu systemd-cryptsetup:
Ganz ein schlauer ist das:

Code: Alles auswählen

systemd-cryptsetup[995]: Key file /dev/urandom is world-readable. This is not a good idea!

Glaube ich doch. Ich glaube meine Sicherheit wäre ziemlich im Eimer, wenn niemand mehr Zufallszahlen bekommen würde…

sdb5_crypt ist das Device für /. Wird entsprechend vom Kernel verwaltet.
systemd-cryptsetup versucht es trotzdem nochmal:

Code: Alles auswählen

systemd-cryptsetup[851]: Volume sdb5_crypt already active.

Ach ne.. Und beim Runterfahren dann:

Code: Alles auswählen

systemd-cryptsetup[2365]: Failed to deactivate: Device or resource busy
systemd[1]: systemd-cryptsetup@sdb5_crypt.service: control process exited, code=exited status=1
systemd[1]: Unit systemd-cryptsetup@sdb5_crypt.service entered failed state

Du sitzt selber auf dem device… Dir ist schon klar das du dich damit selbst zerstören würdest?

[TomL]

Vermutlich willst du dass diese Unit NACH local-fs.target gestartet wird.

Kp. Ich habe das nur eingebaut, weil TomL das gesagt hat.

Nein, der Eintrag "After=local-fs.target" fehlt ja immer noch oben in der Unit! Obwohl ich schon ganz zu Anfang darauf hingewiesen habe und dann noch einmal und Schorsch jetzt auch erneut. BTW, ich halte auch den Type oneshot für falsch - weil es sich hier um fortlaufend verschlüsselte "Kommunikation" handelt, die eben ein Daemon leistet. Ich hätte das vermutlich anders aufgebaut... zunächst mal keine 2 Units, sondern nur 1..... eher so:

Code: Alles auswählen

[Unit]
Description=luks-device.service:   Open local Harddisk as Luks-Device with persistent CryptCredentials
After=local-fs.target
Requires=local-fs.target
ConditionPathExists=/etc/hompw 

[Service]
Type=forking
RemainAfterExit=yes

ExecStartPre=/sbin/dmsetup create ext_cache --table '0 456534016 cache /dev/sda7 /dev/sda8 /dev/sdb4 2048 1 writeback default 0'
ExecStart=/sbin/cryptsetup open --type luks --key-file /etc/hompw --allow-discards /dev/mapper/ext_cache ext_home
ExecStop=/sbin/cryptsetup close ext_home
ExecStopPost=/sbin/dmsetup suspend ext_cache ; /sbin/dmsetup clear ext_cache ; /sbin/dmsetup remove ext_cache 

[Install]
WantedBy=multi-user.target

Und speziell hier hätte ich die Verwendung der fstab sowieso nicht weiter erwogen, sondern direkt über eigene Mount-Units nachgedacht. Wenn ich mehrere Mounts auf dieses Cryptdevice verbinden müsste, würde ich kurzerhand dafür eine eigene Unit mit multiple ExecStarts im Anschluß (after=) dieser Service-Unit ausführen. Und hätte ich nur EINEN Mount, würde ich den einfach direkt hier in der Mitte platzieren, mit Start und Stop, und dann Cryptsetup open/close kurzerhand auf Pre und Post verlegen.... und fertig ist die Kiste.

Das Problem ist, das es speziell hier im Laufe des Thread aufgrund ständig stark gekürzter und unverständlichen Angaben irgendwie immer unheimlich schwer ist, die Probleme überhaupt zu diagnostizieren. Erst anhand der 2 obigen Units kann man erkennen, wie der Hase läuft. Man hatte vorher kaum ein Gesamtbild über Start, Wegstrecke, verwendete "Fahrzeuge", geplantes Ziel und welche Probleme an welcher Stelle auftauchen.

Eigentlich ist das an dieser Stelle ganz einfach... wenn man die Befehle, mit denen man den kompletten Ablauf manuell im Terminal erfolgreich durchführen könnte, einfach auf eine Service-Unit überträgt..... das funktioniert imho immer.

[wanne]

BTW, ich halte auch den Type oneshot für falsch - weil es sich hier um fortlaufend verschlüsselte "Kommunikation" handelt, die eben ein Daemon leistet.

Zuerstmal ist der [Service] Teil das Originalbeispiel (mit angepassten Namen) von feedesktop.org – Also den Machern von Systemd selbst.
Ansonsten ist cryptsetup eben kein Daemon. Es kofiguriert die IO im Kernel lediglich anders statt im Klartext zu schreiben schreibt er danach direkt verschlüsselt. Es beleibt danach kein Prozess übrig der irgend was macht. Lediglich die Arbeitsweise des Kernels wird verändert. Lediglich die Schreibfunktion des Kernels wird verändert. Er muss auch eigentlich überhaupt nicht beendet werden. Das zurücksetzen auf defaults ist eher der Schönheit wegen.

Und speziell hier hätte ich die Verwendung der fstab sowieso nicht weiter erwogen, sondern direkt über eigene Mount-Units nachgedacht. Wenn ich mehrere Mounts auf dieses Cryptdevice verbinden müsste, würde ich kurzerhand dafür eine eigene Unit mit multiple ExecStarts im Anschluß (after=) dieser Service-Unit ausführen. Und hätte ich nur EINEN Mount, würde ich den einfach direkt hier in der Mitte platzieren, mit Start und Stop, und dann Cryptsetup open/close kurzerhand auf Pre und Post verlegen.... und fertig ist die Kiste.
[…]
Das Problem ist, das es speziell hier im Laufe des Thread aufgrund ständig stark gekürzter und unverständlichen Angaben irgendwie immer unheimlich schwer ist, die Probleme überhaupt zu diagnostizieren. Erst anhand der 2 obigen Units kann man erkennen, wie der Hase läuft. Man hatte vorher kaum ein Gesamtbild über Start, Wegstrecke, verwendete "Fahrzeuge", geplantes Ziel und welche Probleme an welcher Stelle auftauchen.
[…]
das funktioniert imho immer.

Wenn es mir nur um dieses eine Problem auf meinem lokalen PC gegangen wäre hätte ich einfach ein bash-Script in die rc.local gehauen und das Problem wäre erledigt gewesen. Oder alternativ einfach SystemV init installiert.

Das Ding ist, dass mir das Abhängigkeitsmanagement in Systemd (Insbesondere mit Devices und mounts) nicht das erste (und auch garantiert nicht das letzte) mal verfolgt.
Auf der Arbeit läuft z.B. parktisch gar nichts direkt über systemd. Startup läuft über Scripte in von Hand gepflegter Reihenfolge, Dann gibts es zwei Monitoring Lösungen von Drittanbietern und jede menge Gefrikel für HA, wenn die was feststellen.
Wäre eigentlich schön, wenn man sowas mit Systemd machen könnte.

Deswegen wäre ich an einer Systemd-Lösung für sowas wie Abhängigkeitsmanagement interessiert gewesen. Eigentlich war das ja für sowas gedacht.
Alles sequenziell in manuell vorgegebenenr Reihenfolge nacheinander in ein bash Script schreiben und mich dann um Monitoring und und Ausfälle von Hand kümmern ist für meinen PC machbar aber für größere Umgebungen absolut untauglich.

Deswegen habe ich den Eigentlichen Inhalt weggelassen. Ich wollte keine Endlosdiskussionen über die eigentlichen Services, und durch was man die alles ersetzen könnte. Sondern ob und wie es möglich ist, Abhängigkeitsmanagement von beliebigen Services Systemd erledigen zu lassen.

Offensichtlich funktioniert das eher nicht. Auch jetzt funktioniert das ganze ja nur, weil das Fehlschalgen von systemd-cryptsetup halt harmlos ist.

[TomL]

Sondern ob und wie es möglich ist, Abhängigkeitsmanagement von beliebigen Services Systemd erledigen zu lassen.
Offensichtlich funktioniert das eher nicht.Auch jetzt funktioniert das ganze ja nur, weil das Fehlschalgen von systemd-cryptsetup halt harmlos ist

Und genau diese Aussage kann ich überhaupt nicht nachvollziehen. Ich glaube fast, dass das Fehlschlagen vielleicht andere Gründe hat. Ich nutze Cryptsetup in mehreren Varianten und unterschiedlichen festen und variablen Devices und fehlerhaftes Abhängigkeitsmanagement habe ich noch nie beobachten können. Meiner Meinung nach ist es gerade unter Systemd wirklich einfach, eine Kette von Abhängigkeiten zu bilden.... es muss dann im Anschluß nur gelingen, diese Kette an die richtige Stelle in den gesamten Boot-Prozess sauber einzufügen. Aber das betrifft dann auch nur wieder das erste Glied dieser Kette. Aber auch dabei kenne ich jetzt keine Probleme mehr. Allerdings fällt mir zu diesem aktuellen Problem jetzt wirklich kein Rat mehr ein....

[schorsch_76]

Meiner Meinung nach ist das Problem, das es an das multi-user.target gehängt ist.

Das Ziel ist ja, ein lokales Filesystem bereit zu stellen das auf einem Software, Kernel block device läuft. Sprich: local-fs.target wäre schon rightig (meiner Meinung nach).

Erst wenn beim Shutdown local-fs.target geschlossen wird, muss auch der dm-cache weg. Dann ist auch sicher kein User mehr eingeloggt und es läuft keine VM mehr. Da wir hier sehr sehr früh im Systemstart sind, müssen die default dependencies ausgeschalten werden. Ein Beispiel ist z.b. di HW Uhr an meinem Pi:

Code: Alles auswählen

cat /etc/systemd/system/hwclock-pi.service 
[Unit]
Description=HWClock at the I2C Bus of the Raspberry pi
Before=basic.target
Conflicts=shutdown.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/sh -c "modprobe i2c_bcm2835 && modprobe i2c_bcm2708 && modprobe rtc_ds1307 && sleep 1 && echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device && /sbin/hwclock -s"
ExecStop=/sbin/hwclock -w
RemainAfterExit=yes

[Install]
WantedBy=basic.target

Hier soll auch sehr früh das Modul geladen werden und ein paar Befehle ausgeführt werden. Oneshot, da kein Prozess da bleibt, der Überwacht wird, wie bei wanne.

Genauso würde ich es auch bei dem ext_home cache machen. Alles in eine Unit, keine default dependencies und WantedBy=local-fs.target und Before=local-fs.target

Ich bin mir nur gerade nicht sicher, ob wanne es an local-fs.target hängen kann. basic.target funktioniert hier bei der Uhr sehr gut.

Siehe auch
https://www.freedesktop.org/software/sy ... ootup.html

Edit: Ich denke local-fs.target ist noch in der initrd. Hier wird es nicht gehen. basic.target ist noch vor allen Diensten.

EDITH: sagt:
Du solltest auch noch überlegen mit was das beendet wird. Ich denke
Conflicts=shutdown.target
Conflicts=sysvinit.target

So macht systemd das:

Code: Alles auswählen

cat  /var/run/systemd/generator/home.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
Requires=systemd-fsck@dev-laptop-home.service
After=systemd-fsck@dev-laptop-home.service

[Mount]
What=/dev/laptop/home
Where=/home
Type=ext4
Options=defaults,discard

[TomL]

Sorry, "DefaultDependencies=no" war ein Fehler von mir, den ich oben korrigert habe. Die Berücksichtigung der DefaultDependencies hier an der Stelle ist m.M.n. absolut korrekt. Und ich bin auch der Meinung, dass die Anbindung an multiuser.target richtig ist.... deshalb, weil ich davon ausgegangen bin, dass es sich bei den "angehängten" Crypt-Devices um reine verschlüsselte Daten-Devices handelt, ohne systemische Bedeutung, die wirklich erst im MultiUser-Level relevant sind. Meiner Meinung nach gibts hier auch keinen Konflikt mit dem Shutdown.Target, weil die Crypt-Ressource tatsächlich dann ordentlich vor dem lokalen Filesystem geschlossen wird, was ja richtig ist. "Conflicts" wäre erst dann notwendig, wenn ein asynchroner Effekt möglich wäre, weil mir der Shutdown beim Schließen von local-fs.target die Filesysteme unterm Hintern wegzieht, bevor das Cryptdevice geschlossen ist.... aber das kann imho wg. "after local-fs.target" nicht passieren.

Und wie gesagt, ich hätte auch nicht 'Oneshot' gewählt, sondern jetzt (ich gebe meinen Irrtum mit 'forking' zu) besser 'simpel' .... aber ich sehe das bei mir auch vor dem Hintergrund, dass ich das alles in einer Unit löse, also den device-mapper, crypt-setup und sofort auch den Mount, und beim Shutdown den gleichen Weg zurück. Da gibts es keine Konflikte oder Umstimmigkeiten mit dem Abhängigkeitsmanagement. Und ich wollte auch nicht, dass es wegen 'oneshot'" wartet, bis alles durch ist und dann erst mit Follow-Up-Units weitermacht. Aber möglicherweise ist das bei hier mehreren verketteten Units ein besserer Weg.... aber requires und after führen imho hier zum gleichen Ziel.