1 |
Hallo, |
2 |
|
3 |
mal eine ganz blöde(?) Frage in die Runde: Wie bändige ich systemd und nfs? |
4 |
|
5 |
Früher hatte ich ohne systemd folgendes Szenario: |
6 |
|
7 |
1. NFS-Verzeichnisse werden beim Client in fstab eingetragen. |
8 |
2. Falls der NFS-Server beim Booten des Client nicht erreicht werden kann, |
9 |
läuft der mount in ein timeout und wird nicht durchgeführt. Danach ist der |
10 |
Client benutzbar, die mountpoints sind halt leer. |
11 |
3. Falls der Server beim Booten erreichbar war, im Betrieb dann aber |
12 |
verschwindet, hängen die Mountpunkte beim Zugriff (kann man über |
13 |
Mount-Optionen anders einstellen). |
14 |
|
15 |
|
16 |
Das fand ich eigentlich sehr praktisch und hätte das nun mit systemd auch |
17 |
gerne weiter so. Leider bekomme ich systemd über die Optionen "nofail" |
18 |
und "x-systemd.device-timeout" zwar dazu, über einen fehlenden Server |
19 |
hinwegzubooten, aber ich habe dann nicht wie früher leere Mountpunkte. |
20 |
Stattdessen versucht systemd bei jedem Zugriff auf den Mountpunkt im |
21 |
Betrieb wieder erneut, die Verzeichnisse einzuhängen, und zwar ohne |
22 |
irgendein Timeout. Soll heißen: bereits ein simples "ls" hängt ewig. |
23 |
Besonders lustig ist das, wenn man wie ich Verzeichnisse mit shared libs |
24 |
auf nfs hat, denn dann hängt das automatische Neubauen vom ld-cache bereits |
25 |
das Booten ewig auf... |
26 |
|
27 |
Ich habe nun per Google eine Menge Leute gefunden, die das gleiche Problem |
28 |
haben, aber niemanden mit einer Lösung. Ich bin kurz davor, meine |
29 |
NFS-Einträge aus der fstab zu entfernen und mir für das Mounting ein |
30 |
einfaches Script und einen systemd-Service dazu zu schreiben, die das dann |
31 |
bitte nur einmal versuchen und nicht das halbe System dauerhaft lahmlegen. |
32 |
|
33 |
Aber kann das die einzige Lösung sein? Kennt jemand eine andere/bessere? |
34 |
|
35 |
|
36 |
cu |
37 |
Gerrit |