Es bleibt dir leider nur übrig per WinSCP zu schauen, wer genau so viel verbraucht - bzw. wie oben vorgeschlagen in der Archiv Instanz zu sehen, welche Variable viel benötigt und dort ausdünnen. Dafür haben wir seit der 6.4 die „Ausdünnen“ Funktion.
paresy
Okay, dass heißt das Ziel muss sein auf eine neuere Version upzudaten um die Logdaten dann komfortabel ausdünnen zu können. Aktuel schlägt die Symbox vor, direkt auf 7.0 upzudaten. Ist das okay? Ich hätte erwartet, dass da noch ein paar Zwischenschritte von Nöten sind.
Ab wieviel Prozent freien Speicher wäre es denn gefahrlos möglich das Update anzugehen?
Was ich noch nicht so richtig verstanden habe:
Für die Auslastung von /mnt/data sind die großen Archive verantwortlich.
Aber warum sind /mnt/symupd und /mnt/symcon auch zu 100% voll?
Gruß Marc
/dev/mmcblk0p3 3.0G 2.5G 303.2M 90% /mnt/data
/dev/loop0 40.3M 40.3M 0 100% /mnt/symupd
/dev/loop1 21.6M 21.6M 0 100% /mnt/symcon
Verstehe ich das richtig, du hast die logging.old mit 463MB gelöscht und trotzdem sind nach dem Löschen nur 300 MB frei?
Ja, genau. Da muss irgendwo ein kleiner Bitfresser in der Symbox leben, der die theoretisch freigewordenen weiteren 163MB aufgefuttert hat. 
Gruß Marc
Die sind real only. Für das OS ist der Speicherplatz auf /mnt/data auch egal. Alle Systemdateien liegen auf /mnt/system. D.h. das System sollte problemlos updaten 
paresy
Kannst Du bitte mal schauen, ob Dir das ArchiveControl eine Reaggregation von Variablen vorschlägt? Wenn ja, kannst Du diese durchführen und danach mal den Speicherplatz prüfen?
Das hatte ich bereits geprüft. Reaggregation wurde für ein paar Variablen vorgeschlagen. Habe dann allerdings alle Variablen reaggregiert. Brachte allerdings keine Besserung.
Als nächstes werde ich das Update auf die 7.0 dirchführen sobald ich etwas mehr Zeit finde (fals Nacharbeiten notwendig sind).
Ein Backup komnte ich Gestern bereits erstellen.
Gruß Marc
Kurze Rückmeldung. Habe soeben auf die 7.0 upgedated. Das System schaut und fühlt sich jetzt deutlich gesünder an:
Sun Dec 3 08:29:59 CET 2023 (Compute Module 3 Rev 1.0)
08:29:59 up 2 min, load average: 0.38, 0.30, 0.12
Linux SymBox 5.10.110-v8 #2 SMP PREEMPT Tue Aug 29 15:36:06 UTC 2023 aarch64 GNU/Linuxtotal used free shared buff/cache availableMem: 979256 141700 459776 47128 377780 774732
Swap: 0 0 0Filesystem Size Used Available Use% Mounted on
devtmpfs 436.1M 0 436.1M 0% /dev
tmpfs 64.0M 0 64.0M 0% /dev/shm
tmpfs 128.0M 372.0K 127.6M 0% /tmp
/dev/mmcblk0p2 379.4M 233.8M 121.6M 66% /mnt/system
/dev/mmcblk0p3 3.0G 1.7G 1.1G 60% /mnt/data
/dev/loop0 53.0M 53.0M 0 100% /mnt/symupd
/dev/loop1 40.0M 40.0M 0 100% /mnt/symcon/dev/loop0: 0 /mnt/system/symupd/symupd_7.0-112_arm64.sqfs
/dev/loop1: 0 /mnt/system/symcon/symcon_7.0-477_arm64.sqfs
Und für Backups ist jetzt auch wieder Speicher frei:
Nichts destotrotz werde ich mich mal dem Thema Archive widmen und für die Variablen, wo keine Langzeithistorie benötigt wird etwas ausdünnen bzw. die Einstellungen anpassen.
Besten Dank an den guten Support hier im Forum schon mal.
Gruß Marc
Ich hab das Problem nach sehr langer Zeit auch mal wieder:
Ich hab allerdings auch sehr viel Fehler im Log. Wo kann ich mir die ansehen?
Denn in den Logfiles in SymOS Oberfläche find ich nix.
Allerdings ist auf der Maschine seit 1 Woche TailScale. Dort steht jede Menge Zeug drin das ich nicht verstehe.
Hier was das System sagt.
Wo setze ich denn da am besten an?
Ah, dann fiel noch was auf. Hab mir auch das Archiv angesehen. 3 Variablen wollten aggregiert werden.
Danke und Gruss
Seppm
PS: Hab jetzt mal nicht neu gestartet, da IPSview läuft. Allerdings kommt mir das ganze Ding sehr langsam vor, werde also spätestens morgen starten da das Ding laufen muss.
Ich Reihe mich mal mit ein, denke das ist das identische Problem. Logfile wird schnell zu groß und aktuell habe ich alle 2Std. einen Neustart.
Regelmäßige ungewollte Neustarts - IP-Symcon - IP-Symcon Community
Leider muss ich mich nochmal melden. Ich bekomme nun wieder diesen Fehler, vermutlich wegen eines bestehenden Fehlers (KNX IP Gateway - Fehlermeldung - #17 von thorsten1)
Gibt es hier irgendwie ein Workaround?
VG
Hallo, ich kann nichts zur Lösung beitragen, habe aber ein ähnliches Problem:
Die Symbox läuft eigentlich. Ich war jetzt längere Zeit nicht mehr eingeloggt, aber kriege die Meldung wenn ich die Verwaltungskonsole öffne:
Ich konnte Module updaten, das neue IP Symcon 7.1 installieren …
aber irgendwie beunruhigt mich die Meldung trotzdem.
Hier die Speicherauslastung:
Tue Jul 9 12:56:48 CEST 2024 (Compute Module 3 Plus Rev 1.0)
12:56:48 up 20 min, load average: 0.47, 0.92, 1.02
Linux SymBox 6.1.61-v8 #2 SMP PREEMPT Mon Feb 12 14:22:49 UTC 2024 aarch64 GNU/Linux
total used free shared buff/cache available
Mem: 979424 281556 39924 79560 657944 602680
Swap: 0 0 0
Filesystem Size Used Available Use% Mounted on
devtmpfs 434.7M 0 434.7M 0% /dev
tmpfs 64.0M 0 64.0M 0% /dev/shm
tmpfs 128.0M 14.2M 113.8M 11% /tmp
/dev/mmcblk0p2 377.1M 288.9M 64.3M 82% /mnt/system
/dev/mmcblk0p3 6.6G 6.3G 0 100% /mnt/data
/dev/loop0 60.1M 60.1M 0 100% /mnt/symupd
/dev/loop1 40.9M 40.9M 0 100% /mnt/symcon
/dev/loop0: 0 /mnt/system/symupd/symupd_7.1-130_arm64.sqfs
/dev/loop1: 0 /mnt/system/symcon/symcon_7.1-540_arm64.sqfs
Schau mal bitte unter Kern Instanzen → Archiv wie viel du verwendest? Und hast du Backups auf der SymBox?
paresy
scheint wohl an den Variablen zu liegen …
gibts da einen schnellen Weg zu komprimieren ?
Am einfachsten per WinSCP reingehen und alte Jahre löschen. Du findest die Ordner in /var/lib/symcon/db/xxxx
Und für mehr Arbeit kannst du die Verdichtung aktivieren für z.B. die größten Verursacher.
paresy
@paresy Guten Morgen!
Seit gestern scheine ich mit meiner Symbox dasselbe Problem zu haben:
Neustart von Symcon oder der SymBox? Das Problem ist leider erst nach einem SymBox neustart gelöst.
paresy
Hier noch ein Querverweis, der zwar mit Tailscale das Problem geklärt, aber es wird hier mit dem SymOS sich ähnlich verhalten: SymBox Fehler bind: Address is in use - #18 von paresy
paresy
