Wie kann ich systemd dazu bringen, mein ZFS-Mount-Skript zu starten, bevor ich etwas anderes mache?


7

Im Moment verwende ich zfsonlinux unter Fedora 19 und es funktioniert hervorragend. Das Mounten funktioniert beim Booten wie geplant mit dem von systemd aufgerufenen Initscript (im Lieferumfang von zfs enthalten), aber es gibt einen ziemlich schwerwiegenden Fehler: ZFS wird viel zu spät beim Booten gemountet, bis die Übertragung und andere Dienste ohne / zfs sehr verloren gehen montiert und kann nicht wiederhergestellt werden, daher scheitern sie.

Was ich suche, ist eine Möglichkeit, systemd dazu zu bringen, das Skript zu starten, bevor etwas anderes getan wird. Ich weiß, wie man es mit Initscripts macht (stellen Sie es einfach auf einen niedrigeren Runlevel ein, sagen wir 2), aber ich habe nicht den geringsten Nebel, wenn es darum geht, es mit dem Zielsystem von systemd zu machen.

Ich habe versucht, Dinge in den Diensten festzulegen, für die zfs aktiv sein muss, aber es funktioniert nicht, außer Type = idle (aber es muss trotzdem eine bessere Möglichkeit geben):

Requires=network.target
After=zfs
Type=idle

Und als Referenz hier das Initscript von Fedora . Aufgrund der Art und Weise, wie ZFS unter Linux (?) Bereitgestellt wird, kann ich nicht einfach einen Eintrag in fstab ploppen und damit fertig sein. Er muss mithilfe von Befehlen bereitgestellt werden.


ungetestet, aber ich glaube, Sie müssen Ihr multi-user.target aktualisieren, um von Ihrem Dienst abhängig zu sein, vorausgesetzt, Ihre anderen Dienste starten nach dem Mehrbenutzer.
BitsOfNix

@ alexandre-alves Ich bin mir nicht sicher, ob Ziele Initscripts abfeuern können (wenn sie können, dann zerschlagen), und im Idealfall möchte ich vermeiden, dass das gesamte Mount-Skript neu geschrieben werden muss, um es systemd bereit zu machen
duck.

Nur ein Gedanke, aber könnte es sein, dass Ihr zfs-Dienst anstelle einer Aufgabe als Daemon behandelt wird? Dh dass das Skript vor den anderen Diensten gestartet wurde, die davon abhängen, aber noch nicht abgeschlossen waren?
MvG

Könnte dies etwas mit Ihren udev-Regeln zu tun haben? Ich bin bereit zu wetten, dass es eine Verbindung gibt
mikeserv

Antworten:


1

systemdhat eine spezielle Richtlinie für diesen Fall, genannt RequiredMountsFor; siehe man systemd.directives.

Die Verwendung wäre RequiresMountsFor=[mountpoint]z RequiresMountsFor=/zfs.

Die Schlüsselfrage könnte sein, ob Sie wirklich eine "alles andere" Bedingung widerspiegeln müssen, wie Ihre Q-Zustände. Ich denke, die Idee ist, diese Abhängigkeiten so selektiv wie möglich zu verwenden, um das Finden der optimalen Sequenz und der maximalen Parallelisierung zu unterstützen.


-1

Ich werde versuchen, so gut wie möglich zu antworten, nicht so vertraut mit systemd.

Das bereitgestellte Skript ist nur ein Standard-Skript, sodass Sie es jederzeit starten können script_name start.

Nach dem, was ich in den Manpages von systemd gesehen habe, können Sie Abhängigkeiten definieren. Am besten verwenden Sie Vorher-Nachher-Ziele. Wenn man sich die Dateien ansieht, gibt es einen Alias ​​von Runlevel 2 3 und 4, der immer multiuser.target sein soll.

Wenn Sie systemctl list-dependencies basic.target ausführen, können Sie leicht herausfinden, wo Ihr Dienst gestartet werden soll.

[Unit]
Description=my Service
Before=basic.target 
After=local-fs.target

[Service]
Type=simple
ExecStart=/path/to/script start
ExecStop=/path/to/script stop

Speichern Sie das Dateibeispiel /usr/lib/systemd/myservice.service. systemctl aktiviere myservice.service.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.