Liebe Community,
ich benutze schon seit Monaten statt der Filelogs DbLog. Ursprünglich hatte ich dafür eine mysql-Datenbank auf meinem Raspberry.
Leider ist mir allerdings vor ein paar Tagen die SD-Karte gecrasht. Da habe ich versucht zu sichern, was noch zu sichern ist. Mit der FHEM Installation und Konfiguration hat soweit bis jetzt alles geklappt. Den Datenbankbestand musste ich aber von vor etwa einem Monat einspielen.
Um diesem Problem zukünftig zu entgehen und eventuell einen kleinen Performance-Vorteil zu erlangen, habe ich nun statt der mysql-Datenbank auf dem Raspberry die mariadb 10 Instanz auf meinem Synology NAS als Datenbank für FHEM auf dem raspberry im Einsatz.
Das Backup von vor etwa einem Monat habe ich also auf der mariadb 10 auf dem Synology eingespielt.
Soweit funktioniert auch alles tadellos. Daten werden anständig geschrieben und die Plots funktionieren damit auch.
Um das Log zu säubern, lasse ich jede Nacht um 3Uhr ein Log-Reduce laufen, welches wie folgt konfiguriert ist:
define Logdb.Reduce at *03:00:00 set Logdb reduceLogNbl 90 average
setstate Logdb.Reduce Next: 03:00:00
setstate Logdb.Reduce 2018-05-01 03:00:00 state Next: 03:00:00
Leider scheint das nicht mehr zu funktionieren. Im Systemlog findet sich folgender Fehler, jeden Tag um 3Uhr:
2018.04.30 03:00:27 2: DbLog Logdb -> DbLog_reduceLogNbl - DBD::mysql::st execute failed: Error writing file '/tmp/MYBOu8vH' (Errcode: 28 "No space left on device") at ./FHEM/93_DbLog.pm line 4203.
Weiß einer was hier los ist?
Liebe Grüße,
Bond
Na ja, sieht so aus, als ob /tmp voll ist. Was sagt denn df -lk ?
Gesendet von meinem Nexus 5X mit Tapatalk
das ist df auf dem lokalen Raspi. Ich hab den Speicher im Vergleich zu der alten microSD (8Gb) auf 16Gb verdoppelt.
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 15240048 3023144 11565104 21% /
devtmpfs 470116 0 470116 0% /dev
tmpfs 474724 0 474724 0% /dev/shm
tmpfs 474724 6380 468344 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 474724 0 474724 0% /sys/fs/cgroup
/dev/mmcblk0p1 43436 22154 21283 52% /boot
tmpfs 94944 0 94944 0% /run/user/1000
Die Frage ist, versucht der FHEM reduce-Prozess auf dem NAS in /tmp/ zu schreiben oder auf dem rasPi?
Ich könnte mir noch vorstellen, dass es ein Rechteproblem ist...
Ich vermute, das kommt vom NAS. Ich schau mir morgen mal mein Synology an. Falsche Rechte geben normalerweise andere Meldungen.
Gesendet von meinem Nexus 5X mit Tapatalk
ich habe zumindest "offiziell" keine weiteren Rechte an den Raspi gegeben, irgendwo weitere Dateien auf dem Synology zu schreiben.
Wenn dann müsste also die mariadb auf dem NAS in ihr eigenes /tmp/-Verzeichnis schreiben.
Auf dem NAS sind noch 20% frei... etwa 3Tb.
Danke für die Hilfe soweit.
Bei den meisten Linuxen ist inzwischen /tmp auf das shared Memory gemounted. Die Synology (meine ist eine DS215J) hat aber nur wenig
bash-4.3# df -lk
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2451064 945904 1402760 41% /
none 254900 4 254896 1% /dev
/tmp 256796 1444 255352 1% /tmp
/run 256796 2308 254488 1% /run
/dev/shm 256796 4 256792 1% /dev/shm
= 250 MB
Du bist nicht der erste mit dem Problem "volles /tmp": zB https://forum.synology.com/enu/viewtopic.php?t=104018 (https://forum.synology.com/enu/viewtopic.php?t=104018).
Du musst mal forschen, ob man für die Maria-DB /tmp auf irgendeinen Disk Bereich umlenken kann. Google "synology mariadb tmpdir" zeigt dir was. Da ich selber die Maria-DB nicht nutze, klinke ich mich an dieser Stelle aus. Viel Glück!
Ich hab mir hierfür endlich mal richtig Zeit genommen und eine Lösung gefunden.
Falls mal jemand das Problem hat:
Unter /var/packages/MariaDB10/etc muss eine my.cnf Datei angelegt werden.
Für den Inhalt der Datei ist folgendes ausreichend:
[mysqld]
tmpdir=/volume1/@maria_tmp
Ich habe mein neues tmp-Verzeichis unter /volume1/ angelegt, weil dort der meiste Platz vorhanden ist.
Außerdem muss das neue Verzeichnis Schreibrechte für alle haben.
chmod a+w @maria_tmp
Man kann sicherlich auch einfach die Besitzrechte anpassen. Ich weiß allerdings nicht, mit welchem Nutzer mariadb bei mir auftritt.
Anschließend muss das Paket neugestartet werden, entweder indem man die Synology Diskstation neustartet oder indem man das Paket neustartet:
/usr/syno/bin/synopkg restart MariaDB10
All diese Aktionen macht man am besten als root-User per SSH auf der Synology.
ssh user@Diskstation
sudo -i
Und dazu jeweils das Kennwort für seinen user angeben.