RaspberryMatic 3.51.6.20200420 – Neue Version

[hammeran]

Seit dieser Version läuft das Script ccu_backup bei mir nicht mehr richtig. Aufruf erfolgt mit

Code: Alles auswählen

/usr/local/addons/cuxd/extra/ccu_backup

folgende Meldung bekommt ich beim Aufruf:

Code: Alles auswählen

SBK-File: /var/tmp/ccu-3.51.6.20200420-2020-04-21-1500.sbk

saving DOM... OK!
creating archive...
tar: The following options were used after any non-optional arguments in archive create or update mode.  These options are positional and affect only arguments that follow them.  Please, rearrange them properly.
tar: --exclude-tag '.nobackup' has no effect
tar: Exiting with failure status due to previous errors
    while executing
"exec tar czf /tmp/usr_local.tar.gz usr/local --exclude-tag=.nobackup"
    (file "/usr/local/addons/cuxd/extra/ccu_backup" line 48)

[jmaus]

Seit dieser Version läuft das Script ccu_backup bei mir nicht mehr richtig. Aufruf erfolgt mit
folgende Meldung bekommt ich beim Aufruf:

Code: Alles auswählen

"exec tar czf /tmp/usr_local.tar.gz usr/local --exclude-tag=.nobackup"
    (file "/usr/local/addons/cuxd/extra/ccu_backup" line 48)

Da muss wohl Uwe bei CUxD das ccu_backup skript ändern damit das mit der aktuellen Version noch funktioniert (die --exclude-tag option muss VOR das /tmp/usr_local.tar.gz. Oder du nutzt einfach das Standard-Backup-Skript das bei RaspberryMatic mitkommt (/bin/createBackup.sh bzw. /bin/cronBackup.sh), das sollte man ohnehin bei Nutzung von RaspberryMatic präferieren.

[hammeran]

Oder du nutzt einfach das Standard-Backup-Skript das bei RaspberryMatic mitkommt (/bin/createBackup.sh

Ich habe die Zeile

Code: Alles auswählen

/usr/local/addons/cuxd/extra/ccu_backup

ersetzt mit

Code: Alles auswählen

/bin/createBackup.sh /var/tmp

Damit läuft alles wieder! - Vielen Dank!!!

[jmaus]

Oder du nutzt einfach das Standard-Backup-Skript das bei RaspberryMatic mitkommt (/bin/createBackup.sh

Ich habe die Zeile

Code: Alles auswählen

/usr/local/addons/cuxd/extra/ccu_backup

ersetzt mit

Code: Alles auswählen

/bin/createBackup.sh /var/tmp

Damit läuft alles wieder! - Vielen Dank!!!

Und was genau liegt bei dir in /var/tmp? Denn in einer Standardinstallation ist das ein tmpfs verzeichnis das im RAM liegt. Wenn das nicht irgendwas spezielles von dir ist, dann wird das unweigerlich dazu führen das irgendwann der RAM von dir voll ist und die CCU stehen bleibt. Wo genau lässt du bzw. willst du denn ein *.sbk Backup erstellen lassen bzw. wo soll es am schluss landen?

[danka]

Raspberrymatic läuft ansonst auch problemlos, nur wie gesagt kein anlernen möglich. Auf dem Funkmodul habe ich auch ein blaues Dauerlicht und sonst keine Regung.
Jemand eine Idee?

Naja, hört sich für mich entweder nach einem Bedienungsfehler beim Anlernprozess an oder das homematic Gerät das du versuchst anzulernen ist bereits angelernt oder eben nicht in den Anlernmodus versetzt worden. Du musst also schon noch mehr beschreiben bevor man dir konkret helfen kann. Welches homematic Gerät willst du denn anlernen, wie bist du vorgegangen, etc. etc.

Ich reihe mich dann mal in die Reihe DAU's ein. (Dümmster anzunehmende User)
Aktor war im "falschen" Pairingmodus. Hat alles geklappt.

@ Jens Maus: Trotzdem vielen Dank für deine schnelle Antwort!

[hammeran]

Und was genau liegt bei dir in /var/tmp? Denn in einer Standardinstallation ist das ein tmpfs verzeichnis das im RAM liegt. Wenn das nicht irgendwas spezielles von dir ist, dann wird das unweigerlich dazu führen das irgendwann der RAM von dir voll ist und die CCU stehen bleibt. Wo genau lässt du bzw. willst du denn ein *.sbk Backup erstellen lassen bzw. wo soll es am schluss landen?

Das ganze ist Teil eines Skriptes das mir ein Backup erzeugt und auf mein NAS kopiert. Ich hatte "/var/tmp" gewählt, da das ccu_backup das auch dorthin geschrieben hat und damit erstmal nur eine Zeile anzupassen war. Aber dank deines Hinweises habe ich nun auch das angepasst und schreibe das Backup direkt auf den Mountpoint vom NAS.

[falno]

Hallo jmaus,

nun ja "Und genauso wird es bei einem Neustart wieder passieren! Also entweder passt du deine eigenen Routinen auf die neuen Gegebenheiten", mache ich halt, denn ich boote direkt von einer ssd, somit ist weder eine SD Karte vorhanden noch ein USB Stick vorhanden, werde die files mit inotifywait überwachen und entsprechend kopieren solange es keine Möglichkeit gibt die *.rrd files woanders hin zu legen bei default. (Rapherry 3B)

Grüsse

Norbert

[jmaus]

Und was genau liegt bei dir in /var/tmp? Denn in einer Standardinstallation ist das ein tmpfs verzeichnis das im RAM liegt. Wenn das nicht irgendwas spezielles von dir ist, dann wird das unweigerlich dazu führen das irgendwann der RAM von dir voll ist und die CCU stehen bleibt. Wo genau lässt du bzw. willst du denn ein *.sbk Backup erstellen lassen bzw. wo soll es am schluss landen?

Das ganze ist Teil eines Skriptes das mir ein Backup erzeugt und auf mein NAS kopiert. Ich hatte "/var/tmp" gewählt, da das ccu_backup das auch dorthin geschrieben hat und damit erstmal nur eine Zeile anzupassen war. Aber dank deines Hinweises habe ich nun auch das angepasst und schreibe das Backup direkt auf den Mountpoint vom NAS.

/var/tmp ist denkbar ungünstig, denn das liegt wie gesagt im RAM und davon hast du begrenzt viel. Wenn dann direkt auf den mountpoint generieren lassen.

Aber wenn du ohnehin schon ein Verzeichnis deines NAS auf einen mountpoint innerhalb RaspberryMatic gelegt hast (was ich übrigens auch habe) würde ich einfach die bereits direkt integrierte cron-basierte Backupmöglichkeit verwenden. D.h. einfach in die Datei /etc/config/CronBackupPath den Pfad (z.B. /mnt) reinschreiben wo das Backup jede Nacht automatisch landen soll. Dann wird RaspberryMatic jede Nacht um 00:07 selbstständig ein *.sbk generieren und dieses in diesen Pfad ablegen. Und wenn da mal >15 Backups liegen wird er das älteste nehmen und entsprechend überschreiben/löschen. Und wenn du die Anzahl anpassen willst einfach in die Datei /etc/config/CronBackupMaxBackups die Anzahl der maximal zu behaltenen Backups reinschreiben (oder 0 wenn man unendlich viele verwahren will). Und wenn du das so umsetzt kannst du komplett auf das selbstständige generieren eines Backups verzichten.

[jmaus]

nun ja "Und genauso wird es bei einem Neustart wieder passieren! Also entweder passt du deine eigenen Routinen auf die neuen Gegebenheiten", mache ich halt, denn ich boote direkt von einer ssd, somit ist weder eine SD Karte vorhanden noch ein USB Stick vorhanden, werde die files mit inotifywait überwachen und entsprechend kopieren solange es keine Möglichkeit gibt die *.rrd files woanders hin zu legen bei default. (Rapherry 3B)

Nun, prinzipiell ist das ja jetzt seit der neuen version möglich und das ist in der ova variante ja auch defaultmäßig so umgesetzt. Nur hab ich dafür NOCH keine Nutzerkonfigurationsmöglichkeit eingeführt. Wenn du aber ein entsprechendes Enhancementticket im GitHub dazu aufmachst und dort den wunsch äußerst das du gerne statt eines externen USB Sticks doch ein selbst gewählten Pfad nutzen willst, dann mach das doch bitte und ich kümmere mich dann drum das man z.B. via einer Datei unter /etc/config selbst den Pfad wählen kann wo die Diagrammdaten, etc. landen sollen.

Bis es allerdings soweit ist kannst du auch einfach wie in der OVA Variante verfahren und einfach folgendes in die /usr/local/etc/rc.init (Nicht in der rc.local !) Datei einbauen:

Code: Alles auswählen

    if [[ ! -e /usr/local/sdcard/.nobackup ]]; then
      mkdir -p /usr/local/sdcard
      touch /usr/local/sdcard/.nobackup
    fi                  
    ln -sf /usr/local/sdcard /media/usb0
    touch /var/status/SDinitialised
    touch /var/status/hasSD

Und dann eben statt /usr/local/sdcard hier einfach den gewünschten Pfad nutzen. Das müsste reichen um den /media/usb0 pfad entsprechend umzubiegen.

[schumla]

Hallo zusammen,
ich habe das Update auch eingespielt. Leider bei mir dauerhaft HMIPServer restarted! Hat jemand eine Idee?