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

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?

Dies ist eine bekannte Einschränkung . Ich wünschte, ich hätte eine Problemumgehung für Sie.

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 ;-)