Systemd-verknüpfte Einheitendateien auf der bereitgestellten Festplatte können nicht geladen werden

8

Wir haben eine interne Anwendung mit systemd-Diensten, die wir außerhalb der normalen systemd-Verzeichnisse (/ etc / systemd / system und / usr / lib / systemd / system) bereitstellen möchten. Dieser Speicherort befindet sich auf einer anderen Festplatte (/ mnt / data im Beispiel).

Der systemd-Dienst wird aktiviert durch:

systemctl enable /mnt/data/sprinterd.service

Dadurch wird eine symbolische Verknüpfung in / etc / systemd / system erstellt

lrwxrwxrwx. 1 root root   27 Jun 20 22:47 sprinterd.service -> /mnt/data/sprinterd.service

Nach dem Neustart wird der Dienst nicht geladen, da die Gerätedatei nicht gefunden werden kann. Von journalctl zuerst ein Fehler, den der Dienst nicht laden konnte, dann der Mount der Festplatte, auf der sich das Gerät befindet.

Cannot add dependency job for unit sprinterd.service, ignoring: Unit sprinterd.service failed to load: No such file or directory.
systemd[1]: Mounted /mnt/data.

Aus / etc / fstab:

/dev/disk/by-uuid/c55e944f-5c63-48ad-8cd2-bd32d7b35c82 /mnt/data auto nosuid,nodev,nofail,x-gvfs-show 0 0

Der Vollständigkeit halber die Serviceeinheitsdatei:

[Unit]
Description=sprinterd

[Service]
Type=simple
Environment=TERM=linux
ExecStart=/srv/s1.erp/bin/sprinterd
Restart=always
RestartSec=5
KillSignal=SIGKILL

[Install]
WantedBy=multi-user.target

Ich habe dies auf RHEL 7 und auf openSuSE 13.2 getestet.

Wird es unterstützt, eine System Service Unit-Datei auf einer anderen Festplatte als / etc oder / usr zu haben? Wie kann die Ausführungsreihenfolge zwischen dem Mounten der Festplatte und dem Laden der systemd-Einheitendateien geändert werden?

systemd Nickvane
quelle
Requires=mnt-data.mount...
Jasonwryan
Nein, immer noch das gleiche. Das Mounten von / mnt / data erfolgt, nachdem systemd die Unit-Datei geladen hat.
Nickvane
Ich denke, Requires, After und RequiresMountFor werden berücksichtigt, wenn der Dienst gestartet wird, aber nicht, wenn er geladen wird.
Nickvane
6
Das Problem ist, dass die Dateien in / etc / systemd Symlinks sind. Wenn systemd gestartet wird, versucht es, sie zu lesen und zu analysieren, bevor ein Dateisystem bereitgestellt wird. Da das Dateisystem nicht gemountet ist, verweist der Symlink nicht auf eine gültige Datei, sodass der Dienst nicht geladen wird. Ich würde gerne eine Antwort darauf erfahren, da ich Einheiten habe, die ich von einem NFS-Server laden möchte und unter dem gleichen Problem leide. Bisher musste ich das Gerät auf die Root-Partition kopieren und aktivieren :-(
Stephen Harris
@ StephenHarris Das liegt systemdan dir, Stephen. Ich habe auch genau das gleiche Problem.
Alecov

Antworten:

2

Wie von @StephenHarris erklärt, besteht das Problem derzeit darin, dass systemd versucht, das Gerät zu lesen. Die mit Symlink verknüpfte Datei ist noch nicht verfügbar

So lassen Sie systemd die Einheiten nach der Montage neu laden:

[Unit]
Description=reloads units stored in /mnt/data
DefaultDependencies=no
After=mnt-data.mount
Requires=mnt-data.mount

[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload

[Install]
WantedBy=local-fs.target

Dadurch werden die Einheiten verfügbar, da diesmal das Ziel der Symlinks gemountet wird.

Zu diesem Zeitpunkt ist die Liste der Jobs, die ausgeführt werden müssen, um das Standardziel zu erreichen, bereits erstellt, und der Dienst wird nicht gestartet.

Damit es auch Ihren Dienst neu startet:

[Unit]
Description=restart unit stored in /mnt/data
Requires=mnt-data.mount

[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload
ExecStartPost=/bin/systemctl start sprinterd.service

[Install]
WantedBy=multi-user.target

Alternativen:

  • Ich habe mit ExecStart=& getestet ExecStartPost=, aber es sollte natürlich mit ExecStartPre=& funktionierenExecStart=
  • Wenn es sich nur um eine einzelne Einheit handelt, können Sie dies auch tun: ExecStart=/bin/systemctl enable /mnt/data/sprinterd.serviceanstelle des Daemon-Reloads
  • Wenn mehrere Dienste vorhanden sind, führen Sie das Daemon-Reload durch und starten Sie eine einzelne Einheit, die alle mehreren Dienste verwendet ConsistsOf=oder PartOf=lädt.
  • Wenn es sich um NFS (oder ein anderes vernetztes System) handelt, ist dies natürlich local-fs.targetnicht die beste Installationsoption.

Für eine Altschule sysvinit -Stil Ansatz, setzen die systemctl Befehle innerhalb /etc/rc.localund chmod +xdiese Datei.

Und dann poste selbstgefällig auf Devuans Mailingliste, wie du SysVInit brauchst, um b0rked SystemD zu reparieren ;-)

DrYak
quelle