reduceLogNbl führt zu Fehler

Begonnen von Bond246, 01 Mai 2018, 14:48:14

Vorheriges Thema - Nächstes Thema

Bond246

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

hotbso

Na ja, sieht so aus, als ob /tmp voll ist. Was sagt denn df -lk ?

Gesendet von meinem Nexus 5X mit Tapatalk


Bond246

#2
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...

hotbso

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


Bond246

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.

hotbso

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.

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!

Bond246

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.