Systemkapazität reicht nicht aus für Updates und Installation von APPs

[geimist]

Das Auswahlfeld wo Voreinstellung steht, musst du anklicken. Dort steht dann "UNIX Epoche zu lokaler Zeit"
Schreiben brauchst du gar nichts.

 

[jan_ds218]

wo?

 

[geimist]

Du warst doch schon dort …

1. Rechtsklick auf die Spaltenüberschrift
2. "Anzeigeformat bearbeiten"



3. auf die Zeile "Voreinstellung" der Auswahlliste klicken und "Unix-Epoche zu lokaler Zeit" auswählen

 

[peterhoffmann]

Mehrfach pro Sekunde. Der Adapter hat wohl durchgedreht bzw. ist mies programmiert.

Ich helfe gerne im Forum, erwarte aber auch hier und da mal eine Antwort auf eine Frage um selbst auch dazu zulernen. Das Thema mit dieser DB gab es schon mehrmals und wird auch in Zukunft mal wieder auftauen.

Daher bin ich nun raus aus dem Thread.

 

[jan_ds218]

wenn du mich meinst, hatte ich noch keine Zeit zu schauen...sorry

 

[jan_ds218]

Guten Abend, ich habe jetzt endlich die Auswertung der Datenbank durchgeführt.
Mit Abschaltung des Synology Adapters hat die Datei keine weiteren Einträge bekommen.
Schlussendlich was das die Ursache die Größe der Datei.
Anscheinend hat der Adapter schon lange Zeit die Datei zugemüllt ohne das ich es gemerkt habe.
Mich würde jetzt aber dochmal interssieren wie das andere User des Synology Adapters machen?
Das kann doch nicht normal sein das hier bei jeder Anmeldung ein Eintrag geschrieben wird?
Anbei nochmal ein Bild von den letzten Einträgen...

 

[Benares]

Schön, dass das nun geklärt ist. 2-5 Anmeldungen/s sind natürlich heftig. Eigentlich ist diese Log-DB für die Aufzeichnung von interaktiven Anmeldungen gedacht, die finden halt nur ein paarmal pro Tag statt. Deshalb gibt es wohl auch keinen Mechanismus zur zyklischen Archivierung/Löschung der Meldungen.

 

[jan_ds218]

Bedeutet aber, das im laufe der Zeit auch bei anderen Usern die diesen Adapter nutzen die Datei sich bis zum Systemausfall stetig vergrößert? Finde es komisch das dies noch nicht früher irgendwo zu Problemen geführt hat…

 

[MBoe]

Guten Morgen,
auch ich bin mit dem Thema überfordert, habe aber schon einige Threads gewälzt.
Ausgangssituation:
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.2G 46M 98% /
devtmpfs 2.9G 0 2.9G 0% /dev
tmpfs 2.9G 180K 2.9G 1% /dev/shm
tmpfs 2.9G 18M 2.9G 1% /run
tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup
tmpfs 2.9G 1.6M 2.9G 1% /tmp
/dev/vg1000/lv 1.8T 366G 1.4T 21% /volume1

-> /dev/md0 ist nahezu voll

mit "du -d 1 -xh / | sort -r -h" habe ich herausgefunden, dass die Ursache wohl in /usr zu finden ist:
2.2G /
2.0G /usr
159M /var
33M /.syno
5.9M /var.defaults
4.0M /etc
2.4M /etc.defaults
1.4M /.log.junior
40K /.old_patch_info
28K /root
16K /volumeUSB1
16K /opt
4.0K /.system_info
4.0K /mnt
4.0K /lost+found
4.0K /initrd

Ist das richtig?

Wenn ja, dann bin ich ab jetzt überfragt.
du -xhd 2 /usr | sort -r -h | head -n 20 liefert mir folgendes:

2.0G /usr
718M /usr/syno
678M /usr/local
497M /usr/syno/synoinstall
452M /usr/local/x86_64-pc-linux-gnu
287M /usr/lib
214M /usr/local/packages
170M /usr/syno/synoman
129M /usr/share
105M /usr/bin
42M /usr/share/geoip
42M /usr/lib/python3.8
28M /usr/share/icu
26M /usr/sbin
25M /usr/share/pgsql
24M /usr/lib/modules
14M /usr/syno/sbin
14M /usr/syno/bin
14M /usr/lib/locale
13M /usr/lib32

In /usr/syno und /usr/local kann ich erstmal nichts erkennen, was ich löschen kann.
Größtes Verzeichnis in /usr/syno ist synoinstall mit 497MB

Innerhalb von synoinstall gibt es nur einen Eintrag:
drwxr-xr-x 2 root root 4096 Oct 12 06:21 .
drwxr-xr-x 24 root root 4096 Sep 16 14:20 ..
-rw-r--r-- 1 root root 537919488 Oct 12 06:33 space-preserve

Was genau ist das für ein Eintrag, und ist das die Lösung meiner Probleme?

Schon mal Danke an alle!

VG, Micha.

 

[Fusion]

Das ist die automatische Platzreservierung die Synology irgendwann eingeführt hat, nachdem sich Leute immer die root Partition voll geschrieben haben.

Normal sollte der DSM die space-preserve automatisch löschen, ein eventuelles DSM Update machen und wenn fertig dann die space-preserve wieder anlegen.

Falls nicht ist er eventuell über irgendwas gestolpert.

Kannst auch probieren die von Hand zu löschen vorher.

 

[geimist]

Normal sollte der DSM die space-preserve automatisch löschen, ein eventuelles DSM Update machen und wenn fertig dann die space-preserve wieder anlegen.

Ich hatte das beim letzten Update beobachtet, solange ich SSH Zugriff hatte (7.1.1 - also kein Minor Update): Es scheint kein Platzhalter zu sein, sondern eher ein Container etc. Während des gesamten Updates blieb diese Datei unverändert erhalten. Ich würde sie also nicht vorschnell löschen.

Welche Probleme hast du denn eigentlich?
Stört dich nur der Wert, oder hast du Probleme beim Update?
Schon mal neu gestartet?

 

[Fusion]

Von wo nach wo war das Update?
Der Platzhalter wurde doch erst mit 7.1 überhaupt eingeführt.
Oder meintest du 'kein Major Update'?
Weil 7.1.> 7.1.1 ist ja ein Minor Update.

Beitrag im Thema 'Freier Platz auf der Systempartition' https://www.synology-forum.de/threads/freier-platz-auf-der-systempartition.121639/post-1008944

 

[MBoe]

Hallo, besten Dank für eure Hinweise,
mich stört nicht die Datei oder deren Größe, mein Problem ist, dass die Systempartition voll ist (und ich dadurch den SMB-Dienst nicht reparieren kann).
Das Ganze kam erst nach dem neuesten DSM-Update (von 7.1.1 auf 7.1.1 Update 1).

Aktuell nutze ich (das was über das normale Maß hinaus geht):
Docker (zwei Container)
MariaDB
PhpMyAdmin
WebStation
HyperBackup

Danke und VG, Micha.

 

[geimist]

Weil 7.1.> 7.1.1 ist ja ein Minor Update.

Mit Minor Update meinte ich die kleinen Updates, welche im DSM auch so gekennzeichnet sind (ich suche gerade nach deren Namen )
Es war von 7.1. auf 7.1.1. Also ein vollständiger Updatelauf mit entsprechender .pat-Größe.

 

[MBoe]

So, Neustart ist durch, hat aber nichts an der Situation geändert...


Details hatte ich weiter oben schon gepostet.

 

[Benares]

Lies mal hier. Da steht auch, wann diese Reservierung eingeführt und warum.
Ich denke, die Datei /usr/syno/synoinstall/space-preserve kann man bedenkenlos weghauen, falls eine Paket-Reparatur mit dem freien Platz Probleme haben sollte. Die wird spätestens beim nächsten Reboot wieder angelegt.

 

[geimist]

452M /usr/local/x86_64-pc-linux-gnu

Diesen Ordner habe ich bei mir nicht an dieser Stelle. Was ist da drin?

/usr/local wiegt bei mir auch nur 239MB. Die Differenz passt ziemlich gut zu diesem Ordner.

 

[MBoe]

in dem Verzeichnis ist das hier drin:

root@DiskStation:/usr/local/x86_64-pc-linux-gnu# dir
total 1512
dr-xr-xr-x 8 root root 4096 Feb 24 2022 .
drwxr-xr-x 12 root root 4096 Oct 14 10:32 ..
dr-xr-xr-x 2 root root 4096 Feb 24 2022 bin
-r--r--r-- 1 root root 1514834 Feb 24 2022 build.log.bz2
dr-xr-xr-x 2 root root 4096 Feb 24 2022 include
dr-xr-xr-x 4 root root 4096 Feb 24 2022 lib
dr-xr-xr-x 3 root root 4096 Feb 24 2022 libexec
dr-xr-xr-x 5 root root 4096 Feb 24 2022 share
dr-xr-xr-x 8 root root 4096 Feb 24 2022 x86_64-pc-linux-gnu

War für mich unauffällg, da irgendwas mit linux steht - und davon habe ich überhaupt keine ahnung...

 

[Benares]

/usr/local/x86_64-pc-linux-gnu gibt's bei mir auch nicht. Überleg mal, was du am 24.02.2022 evtl. installiert hast.
Ich führe immer so eine Art Tagebuch für sowas.

Die space-preserve-Datei muss ja nicht die alleinige Ursache für den mangelnden Speicherplatz sein.

 

[MBoe]

Überleg mal, was du am 24.02.2022 evtl. installiert hast.

Ui, in meinem Alter weiß man nicht mehr was vor 2 Tagen war... Führe halt auch kein Tagebuch...
Ich verschiebe mal den Ordner...