Start- Stop-Script bzw. systemd(?) ärgert mich

[altmetaller]

Hallo,

ich möchte beim Systemstart automatisiert NAS-Freigaben verbinden. Dazu habe ein Script unter /root/nas_mount.sh

Code: Alles auswählen

#!/bin/bash
#
# description: Mountet / Dismountet die NAS-Targets
#

start() {
        logger "Verbinde NAS-Freigaben: "
        mount /buffalo_veeam
        mount /qnap_veeam
        logger "NAS-Freigaben wurden verbunden"
}

stop() {
        logger "Entferne NAS-Freigaben: "
        umount /buffalo_veeam
        umount /qnap_veeam
        logger "NAS-Freigaben wurden entfernt"
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  status)
        echo "Status aller NAS-Freigaben: "
        mount | grep buffalo_veeam
        mount | grep qnap_veeam
        ;;
  restart|reload|condrestart)
        stop
        start
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac

exit 0

Das funktioniert bei händischem Aufruf mit allen Parametern einwandfrei. Im nächsten Schritt habe ich unter /etc/systemd/system/nas_mount.service einen Service erstellt:

Code: Alles auswählen

[Unit]
Description=NAS-Freigaben verbinden
After=network.service

[Service]
Type=oneshot
ExecStart=/root/nas_mount.sh start
ExecStop=/root/nas_mount.sh stop

[Install]
WantedBy=multi-user.target

Nachdem ich den systemd mit "systemctl daemon-reload" neu gestartet habe (muss ich das überhaupt?), beobachte ich folgendes (Fehl-)Verhalten:

• systemctl start nas_mount -> Freigaben werden verbunden und sofort wieder getrennt. Pragmatisch ausgedrückt sieht es so aus, als wenn ExecStop unmittelbar nach ExecStart ausgeführt wird
• systemctl stop nas_mount -> Hier wird mein Script gar nicht erst aufgerufen

Für mich ist das gerade etwas schwierig, weil ich gedanklich noch im SystemV-Initkonzept stecke und gerade erst anfrage, mich reinzufuchsen

Wo liegt der Fehler?

Gruß,
Jörg

Edit: Ich habe gerade festgestellt, dass ich das Verhalten mit RemainAfterExit=true hinter dem ExecStart korrigieren kann. In dem Fall stellt sich allerdings noch die Frage, ob ich den Type in diesem Fall auf oneshot oder eher auf simple stelle...

[smutbert]

Ein Fehler dürfte oneshot sein – nimm stattdessen simple.

Bei oneshot erwartet systemd eine Aufgabe auszuführen und danach gilt der „Dienst“ wieder als beendet – das resultiert genau im beobachteten Verhalten: Es wird eine Aufgabe ausgeführt (start -> mounten) und sobald das erledigt ist, macht systemd alles was zum Beenden erforderlich ist, in dem Fall stop -> unmount.
Du willst dagegen, dass der „Dienst“ aktiv bleibt, dann wird er beispielsweise beim Systemstart gestartet und dann beim Herunterfahren wieder beendet und auch dann erst wird deine Stoppfunktion ausgeführt.

Nachdem du allerdings nichts anderes machst als etwas zu mounten und wieder unzumounten, wäre es einfacher das ganze mit Mount-Units bzw. fstab-Einträgen (die dann wieder zu mount-Units werden) zu lösen. Abhängigkeiten kann man dort denke ich genauso festlegen wie man es auch bei service-Units kann.

[altmetaller]

Hallo,

danke für die Rückantwort.

Das mit den mount-units kannte ich tatsächlich noch nicht. Allerdings stellt sich mir in dem Fall die Frage, wie das System dann reagiert, wenn die NASs beim Start nicht erreichbar sind.

Es handelt sich um ein Notebook, dass ggf. auch mal ohne Netz oder in einem Fremdnetz betrieben wird. Meine Idee war, dass das System in dem Fall halt nicht beim booten stehenbleibt und auch nicht ewig auf einen Timeout wartet.

Da ich den Backup-Job "sporadisch nach getaner Arbeit von Hand" starte, kann ich mir eine gewisse Verzögerung beim mounten gewiss leisten.

Was mich gerade viel mehr nervt ist, dass ich erst im Nachgang festgestellt habe, dass veeam zumindest in der Free- und Workstationvariante "nur" einen Job konfigurieren kann. Irgend etwas ist immer *seufz*

Gruß,
Jörg

[smutbert]

Es gibt für so gut wie alles Mountoptionen, nofail soll dafür sorgen, dass der Systemstart weitergeht, auch wenn etwas nicht gemountet werden kann, noch praktischer oder besser wäre aber vielleicht x-systemd.automount, damit beim Zugriff versucht wird automatisch zu mounten. Die Optionen für einen fstab-Eintrag für Netzwerkdateisysteme könnten etwa so aussehen

Code: Alles auswählen

Adresse   /mnt/network   protokoll/dateisystem   noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev   0   0

(systemd macht dann daraus, wie aus allen fstab-Einträgen eine mount-Unit)

[altmetaller]

Hallo,

geht das denn auch mit cifs usw.? Im Moment sehen die Einträge in meiner fstab in etwa so aus:

Code: Alles auswählen

//buffalo.lan.kneipe/veeam	/buffalo_veeam	cifs	credentials=/root veeam_cred,sec=ntlmv2,vers=2.0,uid=0,gid=0,file_mode=0600,dir_mode=0700 0 0
//qnap.lan.kneipe/veeam		/qnap_veeam	cifs	credentials=/root/veeam_cred,sec=ntlmv2,vers=2.0,uid=0,gid=0,file_mode=0600,dir_mode=0700 0 0

Um's mal reinzukopieren, hätte ich dann:

Code: Alles auswählen

//buffalo.lan.kneipe/veeam	/buffalo_veeam	cifs	noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev, credentials=/root veeam_cred,sec=ntlmv2,vers=2.0,uid=0,gid=0,file_mode=0600,dir_mode=0700 0 0
//qnap.lan.kneipe/veeam		/qnap_veeam	cifs	noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev, credentials=/root/veeam_cred,sec=ntlmv2,vers=2.0,uid=0,gid=0,file_mode=0600,dir_mode=0700 0 0

Anzumerken wäre noch, dass es sich zumindest bei dem Buffalo um ein unglaublich altes NAS (allerdings mit frischen Festplatten) handelt - deshalb auch die Tricksereien mit dem fest eingetragenen NTLM- und SMB-Protokoll. Mein Hardwarebudget ist halt etwas "übersichtlich"
Gruß,
Jörg

[smutbert]

Ja, das sollte mit allen Dateisystemen funktionieren.