CustomStoragePath funktioniert nicht (für Diagramme) wenn der Pfad über rc.local gemountet wird

[Baxxy13]

Describe the bug
Wenn man usr/local/etc/config/CustomStoragePath nutzen möchte um z.B. die Diagrammdaten (auf einem via rc.local gemountetem NAS-Verzeichnis) zu speichern, dann funktioniert das nicht korrekt. Der Grund ist das der mount mittels rc.local erst nach dem Start des HmIP-Servers (und dessen Diagrammfunktionalität) stattfindet.

Steps to reproduce the behavior

1. usr/local/etc/config/CustomStoragePath mit dem Inhalt /mnt anlegen
2. /usr/local/etc/rc.local anlegen und damit z.B. ein Netzlaufwerk mounten
3. ein Diagramm anlegen und etwas aufzeichnen
4. Zentrale rebooten
5. Diagramm kontrollieren, alle alten Diagrammdaten sind weg

Expected behavior
CustomStoragePath sollte auch für Diagrammdaten uneingeschränkt nutzbar sein

Screenshots
...

System information:

• RaspberryMatic Version: 3.59.6.20210807
• Used Hardware: Pi3B+
• Used HomeMatic RF-Module: RPI-RF-MOD auf GPIO

Additional context

• Mountet man über CUxD ist CustomStoragePath auch mit Diagrammen funktional. Aber nicht jeder hat oder möchte CUxD nutzen.
• Über die /etc/fstab ginge es auch, aber das ist ja weder upgradefest noch im Backup drin.

Idealerweise würde eine Möglichkeit implementiert einen Mount zu etablieren bevor der HmIP-Server startet, welche upgradefest und im Backup enthalten ist.

[Baxxy13]

So habe mit meinen rudimentären Linux-Kenntnissen etwas experimentiert und herausgekommen ist ein erster Entwurf einer
"MountOnBoot"-Option für RaspberryMatic.

Das ganze läuft zweigeteilt ab:

1. Konfigurations-Datei /usr/local/etc/config/MountOnBoot mit folgendem Inhalt:

MOUNT_TARGET_IP:192.168.1.66
MOUNT_COMMAND:mount -t cifs -o noserverino,vers=3.11,username=USER,password=PASS //192.168.1.66/fritz.nas/test/RM_B /usr/local/fritz_mount

2. Init-Script /etc/init.d/S60MountOnBoot mit folgendem Inhalt:

#!/bin/sh
# shellcheck shell=dash disable=SC2169 source=/dev/null
#
# init script to mount a network-share during boot bevore HmIP-Server starts
# by Baxxy

# source all data from /var/hm_mode
#[[ -r /var/hm_mode ]] && . /var/hm_mode

# skip this startup if not in normal mode
#[[ "${HM_MODE}" != "NORMAL" ]] && exit 0

# skip startup if MountOnBoot-File isn't found
[[ -x /usr/local/etc/config/MountOnBoot ]] || exit 0

start() {
    if [[ ! -e /etc/config/safemode ]]; then
    TARGET=$(grep MOUNT_TARGET_IP: /usr/local/etc/config/MountOnBoot | cut -d: -f2)
    COMMAND=$(grep MOUNT_COMMAND: /usr/local/etc/config/MountOnBoot | cut -d: -f2)
    echo -e "Starting MountOnBoot - pinging NAS-IP: $TARGET \n"
    ping -c 1 $TARGET
if [ $? -eq 0 ]; then
    echo -e "\nPing OK, NAS-Share on $TARGET will be mounted...\n"
    $COMMAND
   else
    echo -e "\nPing fails, NAS-Share on $TARGET will not mounted!\n" 
   fi
    else
    echo "skipping MountOnBoot (safemode)"
 fi
}

restart() {
  start
}

case "$1" in
  start)
    start
  ;;
  stop)
    # nothing
  ;;
  restart|reload)
    restart
  ;;
  *)
    echo "Usage: $0 {start|restart}"
    exit 1
esac

exit $?

Funktionsweise kurz erklärt:

• Es wird auf Vorhandensein von /usr/local/etc/config/MountOnBoot geprüft
• Wenn vorhanden wird die hinterlegte IP-Adresse 1x angepingt
• Wenn der Ping ok ist wird der hinterlegte Mountbefehl ausgeführt

Hinweis!

Auf einem Testsystem hier funktioniert das soweit problemlos.
Das Script muss aber noch auf Abhängigkeiten, Fehlerbehandlung und Exit Codes geprüft / optimiert werden.
(Ich habe als Vorlage S97CloudMatic benutzt)
Auch ist mir unklar ob S60xxx soweit korrekt wäre.
Nur getestet mit IP-Adressen, nicht mit Hostnamen.
Für lokale Mounts (zB. sda4) nimmt man die IP: 127.0.0.1

Wäre schön wenn das in der Art als neues Feature in RM einziehen könnte.

[jens-maus]

So habe mit meinen rudimentären Linux-Kenntnissen etwas experimentiert und herausgekommen ist ein erster Entwurf einer "MountOnBoot"-Option für RaspberryMatic.
[...]
Wäre schön wenn das in der Art als neues Feature in RM einziehen könnte.

Wenn es nicht exakt so mittels neuem init skript sein muss, dann spricht prinzipiell nichts dagegen das es in Zukunft eine Möglichkeit geben wird um solche Aktionen wie das mounten externer shares direkt nach dem hochfahren des Netzwerkes direkt in RaspberryMatic umzusetzen. Allerdings würde ich das nicht als init skript wie du das jetzt umgesetzt hast machen, sondern im grunde "nur" einen weiteren /usr/local/etc/rc.net (oder so) einführen, der direkt nach dem hochgefahrenen Netzwerk ausgeführt wird, wenn er existiert und man nicht gerade in den "safemode" bootet. Hier extra einen init skript einzuführen, sogar mit ping option halte ich für etwas over-the-top und nicht nötig in der Intensität. Wäre das auch ok für dich?

[Baxxy13]

Danke für's Feedback!

Wäre das auch ok für dich?

Na klar.
Primär geht's ja nur darum den Mount rechtzeitig zu etablieren. Wie das vonstatten geht ist da für mich eher zweitrangig.
Wichtig wäre mir nur das es durch den User konfigurierbar ist, Systemupdates übersteht und auch im Backup mit drin ist.

Könnte man mit dieser /usr/local/etc/rc.net (oder so) dann auch lokale Dateisysteme (bspw. sda4; sdb1) mounten oder wäre das nur für Netzwerk-Mounts?

[jens-maus]

Ok, hab das nun entsprechend umgesetzt. Es gibt jetzt mit dem nächsten nightly snapshot an die Möglichkeit einen /usr/local/etc/rc.prelocal skript anzulegen, welcher unmittelbar vor dem starten der addons und vor dem starten der homematic dienste ausgeführt wird (wenn er existiert). Da drin kann dann ein Nutzer ggf. seine mount befehle oder ähnliches ausführen lassen wie du das hier prinzipiell beschrieben hast. Das sollte es somit erlauben z.B. ein netzwerk-basiertes NFS oder CIFS Laufwerk zu mounten das man dann via CustomStoragePath nutzen kann damit der HMIPServer darin dann seine Diagramme usw. ablegt.

[jens-maus]

BTW: Achja, zwecks Dokumentationszwecken könnte ja mal jemand überlegen im Wiki zu diesen /usr/local/etc/rc.XXXX skripten eine Dokumentation unter "Experten-Features" abzulegen wo das ganze z.B. via einer tabelle kurz dokumentiert ist damit nutzer darüber auch besser bescheid wissen.

[Baxxy13]

Sehr schön, habe schon gesehen das du fleißig warst.
/usr/local/etc/rc.prelocal ist dann also genauso "ausführbar" wie /usr/local/etc/rc.local ?
Also "ausführbar" machen und im Kopf #!/bin/sh verankern?

BTW:

Zwei Doofe ein Gedanke.
Du bekommst im Forum gleich eine PN.

[jens-maus]

Sehr schön, habe schon gesehen das du fleißig warst.
/usr/local/etc/rc.prelocal ist dann also genauso "ausführbar" wie /usr/local/etc/rc.local ?
Also "ausführbar" machen und im Kopf #!/bin/sh verankern?

Genau so ist es. Und was du da drin machst bleibt dir überlassen und wer da dann z.B. rm -rf /usr/local/* reinschreibt und damit seine gesamte Konfiguration löscht ist eben selber schuld ;-)

[Baxxy13]

Ok, hab das nun entsprechend umgesetzt.

Mir ist jetzt noch eine zeitliche Inkonsistenz aufgefallen...

/etc/init.d/S06InitSystem

 # users can override the storagePath by specifying an own storage
  # path in /etc/config/CustomStoragePath
  if [[ -f /etc/config/CustomStoragePath ]]; then
    storagePath=$(cat /etc/config/CustomStoragePath)
  fi

  # in case a storagePath is specified we make sure it is setup
  # correct and in case it is empty or does not exist we skip this
  # so that the WebUI will remind users to insert an USB drive for
  # storing diagrams+backups
  if [[ -n "${storagePath}" ]] && [[ -d "${storagePath}" ]]; then
    if [[ ! -d "${storagePath}/measurement" ]]; then
      mkdir -p "${storagePath}/measurement"
    fi
    if [[ ! -e "${storagePath}/.nobackup" ]]; then
      touch "${storagePath}/.nobackup"
    fi
    ln -sf "${storagePath}" /media/usb0
    touch /var/status/SDinitialised
    touch /var/status/hasSD
  fi

Das Anlegen von /measurement und .nobackup schlägt natürlich fehl weil der Mount zu diesem Zeitpunkt noch nicht etabliert ist.

Edit:
Wenn man auf dem Nas-Share /measurement selbst anlegt kann man das ignorieren, andernfalls werden die Diagrammdaten nicht gespeichert.
.nobackup scheint auch irrelevant zu sein, die Daten hinter dem Mount landen ja nicht mit im Backup.

Edit2:
Das Problemchen tritt nur auf wenn man /mnt als CustomStoragePath nutzt.
Habe es jetzt mal mit /usr/local/fritz_mount als CustomStoragePath probiert, das scheint zu laufen.

[jens-maus]

@Baxxy13 Danke für diesen Hinweis. Ich hab das ganze jetzt mal an die Stelle verschoben wo eigentlich es relevant ist das der Pfad da stimmt usw (S62HMServer). D.h. nun sollte es funktionieren das man dort einen frischen Pfad in rc.prelocal angibt der noch kein measurement verzeichnis hat und dann sollten alle vorbereitungen, usw. getroffen werden. Bitte das mit dem nächsten nightly snapshot entsprechend testen.

Auch nochmal danke für deine Dokumentationsanpassungen, das war schon alles recht perfekt :) Hab aber nochmal das ganze basierend auf deinen Vorarbeiten etwas genauer versucht zu dokumentieren und dort auch nun eine Tabelle hinterlegt, sodass einem nun hoffentlich die vielfältigen Möglichkeiten klarer erscheinen :)

[Baxxy13]

nun sollte es funktionieren

Ja, das sieht heute gut aus. In einem leeren (über rc.prelocal gemounteten) Verzeichnis auf dem NAS wird nun korrekt das Verzeichnis /measurement sowie die Datei .nobackup angelegt.

Damit ist das m.E. jetzt vollumfänglich und problemlos nutzbar.
Sehr gut!

[Baxxy13]

nun sollte es funktionieren

Ich bin nun doch noch auf ein weiteres Problem bezüglich CustomStoragePath gestoßen.

Auch wenn ein USB-Stick prinzipiell bei Nutzung von CustomStoragePath nicht mehr nötig ist kann man absichtlich/unabsichtlich einen angeschlossen haben.
Das führt dazu das der Stick (/dev/sda1 on /media/usb1 type f2fs...) korrekt nach usb1 gemounted wird und /media/usb0 dorthin verlinkt wird.
Der CustomStoragePath erscheint dann nur als Link auf dem Stick.

Das führt dann durch den Eintrag...
*/10 * * * * [ -d /media/usb0/measurement ] && /bin/nice /usr/bin/rsync -aogX --delete-after --no-whole-file --checksum /tmp/measurement/ /media/usb0/measurement/ >/dev/null 2>/dev/null

in der /etc/crontab.root dazu, das die Diagrammdaten in /media/usb1/measurement und nicht im CustomStoragePath gespeichert werden.

Ich glaube gestern war das noch nicht so, könnte also mit der geänderten Zeitabfolge zu tun haben.

Edit:
Bin auf den gestrigen Nightly zurück. Hier wird noch korrekt /media/usb0 auf den CustomStoragePath verlinkt. Der Stick ist war auch hier als /media/usb1 eingebunden, wird aber korrekterweise nicht verwendet.

[jens-maus]

@Baxxy13 So, hab mir das mal angeschaut und ich denke den Grund dafür gefunden. Teste das bitte mal mit dem nächsten nightly build sobald der da ist und melde dich mal zurück. Auch an anderen stellen habe ich diesen fix umgesetzt und ich hoffe das da ggf. bisher nicht bekannten probleme auch beseitigt sind. Danke auf jedenfall für den Hinweis! Wieder eine Sache hoffentlich besser.

[Baxxy13]

Teste das bitte mal

Habe mit dem heutigen Nightly (3.59.6.20210815-84481c) nochmal alle möglichen Konstellationen durchprobiert.
Kurz und knapp: Läuft!

[rudelm]

Danke für eure Arbeit! Ich habe gerade nach genau nach der rc.prelocal Datei gesucht und hatte den Wiki Eintrag https://github.com/jens-maus/RaspberryMatic/wiki/Experten-Features#individueller-diagrammbackup-speicherpfad gefunden. Leider stand aber nicht dran, dass man das nur mit dem letzten nightly so machen kann. Ich konnte scheinbar die Seite ändern und habe es mal entsprechent mit einer Warnung versehen.

Übrigens habe ich so etwas schon einmal am laufen gehabt. Das war aber noch Ende 2020 mit der Version 3.53.30.20200919. Leider ist wohl die Backup Methode dann mal überschrieben worden. Die neue gefällt mir dafür umso besser.

Danach muss es irgendwann mal bei einem Update kaputt gegangen sein und mir ist es jetzt erst aufgefallen, dass es nicht mehr lief.

[Baxxy13]

dass man das nur mit dem letzten nightly so machen kann

Ja, die rc.prelocal wurde erst kürzlich Aufgrund dieses Issues eingeführt. Die anderen 3 "Startscripte" gab es schon vorher, die waren aber nicht wirklich dokumentiert. Ich passe deinen Wiki-Eintrag noch etwas an.
Danke für's Feedback!

[rcccbs]

In [https://github.com//issues/1377#issuecomment-898872757] wird der eigentlich nicht mehr benötigte USB Stick bei der Nutzung des CustomStoragePath in Verbindung mit der rc.prelocal beschrieben. Seit dem letzten Update auf Version: 3.69.6.20230407 (rpi3) laufen die Diagramme bei mir nur noch, wenn kein USB Stick steckt. Ansonsten kommt immer die Meldung, dass kein USB Stick vorhanden sei, obwohl der gemountete Pfad zum NAS vorhanden ist. Vielleicht ist es auch nur ein Problem bei meiner Hardware: Raspberry Pi 3 Model B Rev 1.2 (rpi3). Habe den USB Stick entfernt: Läuft wieder wie vorher. Diagrammdaten landen auf dem NAS.

[jens-maus]

Das hier ist ein geschlossenes Ticket und kein Diskussionsforum. Hier geht es nicht weiter. Bitte einen entsprechenden neuen Beitrag im Diskussionteil eröffnen wenn irgendwas nicht geht und man nach Hilfe sucht.