Hallo,
diesen Fehler habe ich auch schon seit langem.
Grüße Michael
Ich denke die Ursache endlich gefunden zu haben. Ein Fix kommt dafür zur 6.0 RC2.
paresy
1 „Gefällt mir“
Das freut mich auch. 
Grüße,
Kai
Ich muss diesen Thread nochmal wiederbeleben, da bei mir das Problem mit der 6.0 Release Version nach wie vor auftritt.
Die df Ausgabe ist dann wie folgt:
Tue Nov 30 16:35:21 CET 2021
16:35:21 up 1 day, 2:03, load average: 0.31, 0.25, 0.20
Linux SymBox 4.14.114-v7 #2 SMP Sat Aug 14 11:15:41 UTC 2021 armv7l GNU/Linux
total used free shared buff/cache available
Mem: 996388 152920 523784 137484 319684 710528
Swap: 0 0 0
Filesystem Size Used Available Use% Mounted on
devtmpfs 474.5M 0 474.5M 0% /dev
tmpfs 64.0M 0 64.0M 0% /dev/shm
tmpfs 128.0M 123.3M 4.7M 96% /tmp
/dev/mmcblk0p2 379.4M 202.3M 153.1M 57% /mnt/system
/dev/mmcblk0p3 3.0G 130.9M 2.7G 4% /mnt/data
/dev/loop0 40.3M 40.3M 0 100% /mnt/symupd
/dev/loop1 21.6M 21.6M 0 100% /mnt/symcon
/dev/loop0: 0 /mnt/system/symupd/symupd_6.0-27.sqfs
/dev/loop1: 0 /mnt/system/symcon/symcon_6.0-122.sqfs
tmpfs hat also scheinbar zu wenig Platz frei. Wenn ich mir das Verzeichnis ansehe, ist das aber mehr oder weniger leer. Ein du auf das Verzeichnis sagt mir, dass da nur 412 KB drin sind…
Ein Reboot der Symbox hat jetzt Abhilfe geschafft. Die tmpfs Auslastung ist jetzt wieder auf 0%. Es ist aber nur eine Frage der Zeit, bis das Problem wieder auftritt…
Bernd
Magst du mal schauen welche Logfiles du hast? Normalerweise werden alle Logfiles sauber rotiert, sodass die Platte zwar voll sein darf, aber nicht die Fehlermeldung mit dem kritischen Speicherplatz bringt. Zur 6.1 korrigieren wird noch das Problem, dass wir die access*.log Dateien nicht rotiert haben. Hast du evtl. diese aktiv?
paresy
Hi,
so ganz scheint das Problem bei mir nicht gelöst zusein.
Ich kann im LogFile Verzeichnis 2 Files finden.
Erwartet hätte ich mehrere File über die letzten Tage. Das File selbst start um 15:00Uhr.
Erster Eintrag:
03/17/22 15:09:00 | 00000 | SUCCESS | Kernel | Rotation der Logdatei aufgrund von Speicherknappheit…
03/17/22 15:09:00 | 00000 | MESSAGE | Kernel | Aufräumen des Logdatei Ordners…
Speicher sollte an sich genügend da sein…?
Was kann ich machen um mehr Logfiles erleben zu können?
Gruß
Jan Peter
Leider garnichts, da wir nur 100 MB vom RAM für die logfiles nehmen, um das Flash zu schonen.
Du kannst nur prüfen warum deine Logs so riesig sind und dann per Spezialschalter z.B. ausdünnen.
paresy
Hallo,
ist das schon gelöst? Ich habe mit der Version 6.3 auch das Problem wie oben geschrieben.
Oder habe ich tatsächlich einen Fehler? Ist mein Speicher voll?
Vielen dank und einen schönen Abend
Micha
Welche Fehlermeldung kommt denn genau?
paresy
Kannst du mal bitte ein Bild von Support → Logfiles geben. Würde gerne mal sehen, welche Logfiles dort Platz klauen.
paresy
Hi Michi,
passiert das Problem immer noch? Ich würde mir das gerne mal bei dir ansehen, da laut deinen Screenshots ja eigentlich gar nicht wirklich Logfiles da sind die Platz verbrauchen.
paresy
1 „Gefällt mir“
Hallo,
Ich hatte vor einer Woche das letzte Update installiert, seit dem ist es nicht wieder aufgetreten. Zur Zeit habe ich null Fehler im Meldungsspeicher.
Vielen Dank der nochmaligen Nachfrage.
Viele Grüße Michi
Das ist ein wenig zu wenig. Magst du mal bitte http://symbox.local/#resize aufrufen?
Ist die SymBox neu? Oder frisch nach einem Recovery?
paresy
Hallo @paresy ,
bei mir kam es auch jetzt in letzter Zeit öfters vor, dass sich Symcon aufhängt (Konsole nicht erreichbar, ssh und ping gehen). Erst ein kompletter Neustart der gesamten Symbox hat geholfen. loop0, loop1 und tmpfs sind voll ausgelastet. Zur Konfiguration, ich habe eine Symbox im Metallgehäuse, ca 3-5 Jahre alt.
Nach dem Neustart sind die Logdateien natürlich klein, aber vorher kam ich nicht mehr bis zu den Logdateien durch.
Welche Ursachen könnte die hohe Auslastung haben und wie bekomme ich sie runter?
Schöne Grüße
Stefan
Hi Stefan,
kannst du mal vor dem Neustart im SymOS schauen welche Logfiles denn den Platz belegen? Wir rotieren diese nämlich immer bevor der Platz zu voll wird. Am Ende sollte eine zu volle Logfile Partition aber trotzdem keinen Absturz verursachen.
paresy
