Root Partition voll

[Shannachie]

Hallo zusammen,

Ich bin auf meiner DS720+ inzwischen mit DSM 7.0-41890 unterwegs und
mein md0 steht plötzlich auf 100% Usage. Der Hauptübeltäter ist wohl /var/log/synolog/.SYNOCONNDB

-rw-rw----  1 system log  1013387264 Aug 26 12:27 .SYNOCONNDB

Archivierte Logs habe ich schon mal gelöscht, aber das ist nur der Tropfen auf nen heißen Stein. Es bleibt bei 100% Auslastung von /
Die .SYNOCONNDB einfach im laufenden Betrieb zu löschen, davor schrecke ich gerade noch zurück.

Ein Supportticket kann ich nicht absetzen, da:









Das Verzeichnis /usr leistet ebenfalls seinen Beitrag zu den 100% auf /



Für mich aber schwieriger zu beurteilen als die Inhalte auf /var/log.

Jetzt hoffe ich hier auf Hilfe, da die Syno natürlich manche Funktionen damit eingestellt hat; Backup auf die zweite Syno inklusive...

Schöne Grüße
Alex.

 

[Benares]

Du könntest dir vielleicht erstmal damit helfen, dass du die DB auf Volume1 verschiebst und durch einen Link ersetzt. So ist es ja bei ein paar anderen synolog-DBs auch, also z.B.

cd /var/log/synolog
mv .SYNOCONNDB /volume1/@database/synolog
ln -s /volume1/@database/synolog/.SYNOCONNDB .SYNOCONNDB

Aber finde erstmal heraus, was dir die DB sooooo zumüllt, z.B. mit "strings .SYNOCONNDB" kann man schon einiges sehen. Da gibt es bestimmt auch Einstellungen dazu. Evtl läuft ja auch irgendwas amok.

Edit:
Hab noch einen anderen Befehl gefunden, mit dem man sich den Inhalt anschauen kann

sqlite3 -header -csv /var/log/synolog/.SYNOCONNDB "select * from logs;"

 

[himitsu]

sqlite3 /var/log/synolog/.SYNOCONNDB

oder

sqlite3
.open /var/log/synolog/.SYNOCONNDB

oder z.B. einen Editor ala sqliteman
https://sourceforge.net/projects/sqliteman/files/latest/download
http://sqlitebrowser.sourceforge.net/
...

Aber wohl besser eine Kopie öffnen, da bestimmt schon geöffnet.

 

[Shannachie]

Danke schon mal für die Rückmeldungen; es erhellt sich.
die sqlite Tabelle enthält unzählige Zeilen

1785076|1629836258|warning|SYSTEM|Host [192.168.1.155] failed to connect via [SMB] due to [SMB1 not permitted].|||192.168.1.155|SMB||

Also Amok
Vermuteter Grund: Ich habe SMB1 erlauben müssen nach der Umstellung auf DSM 7, um die Syno-Shares wieder in Win 10 einhängen zu können.
Kann es mit dieser Einstellung zusammenhängen?

Ich frage mich, warum er die Log-Datei nicht irgendwann durchrotiert/archiviert.

 

[Benares]

Dann schalt mal auf dem 192.168.1.155 SMB1 und NTLMv1 ab,. damit erstmal Ruhe einkehrt.
Wie/wann Synology sein Log-DBs durchrotiert/archiviert weiß ich nicht. Vermutlich rechneten die bei .SYNOCONNDB nicht mit einem so hohen Log-Aufkommen und haben die deshalb in der Root-Partition belassen.

Edit:
Vielleicht genügt es ja auch, einfach im Protokoll-Center die Protokolle zu löschen.

 

[Shannachie]

Hi Benares,
eben geguckt: Das ist meine Sonos, wegen der hatte ich den Aufstand gemacht mit NTLMv1, nicht wegen Win10. Die Sonos fährt leider noch mit SMB1.
Hab jetzt mal NTLMv1 deaktiviert und die Sonos vom Netz genommen.

Siehst Du ne Möglichkeit oder Gefahr, die Logdatei per sqlite Befehl zu entmüllen, obwohl im laufenden Betrieb?

 

[Benares]

Probier mal mein Edit aus #5

Und wenn deine Sonos SMB1 und NTLMv1 brauchen, kannst du das auf der DS auch ruhig eingeschaltet lassen. Prüf aber, dass nichts mehr geloggt wird.

 

[himitsu]

Entsprechend dem SELECT-Beispiel von Benares,
einfach mit einem DELETE im Aufgabenplaner.

sqlite3 -header -csv /var/log/synolog/.SYNOCONNDB "delete from logs;"

-- oder
sqlite3 -header -csv /var/log/synolog/.SYNOCONNDB "delete from logs where msg like 'failed to connect';"

 

[Benares]

Ich hab grad mal eben alle meine Logs übers Protokoll-Center gelöscht. Die Logs sind nun zwar leer, aber die DB-Files wurden nicht kleiner.

Auch ein ergoogeltes

sqlite3 /var/log/synolog/.SYNOCONNDB 'VACUUM;'

ändert daran nichts.
Da muss es noch was anderes geben

 

[Shannachie]

Yepp, bei mir ebenfalls keine Änderung über das Protokollcenter. Alles leer und trotzdem ....

 

[himitsu]

Bei Shannachie ist es kein Wunder.
Für VACUUM wird erst eine kleine Tempdatei (Kopie) der DB-Datei erstellt und dann via Transaktion die Daten "neu" in die alte Datei zurückgespielt.
Es braucht also erstmal mehr Speicher, bevor es weniger wird, Welcher hier eventuell fehlt.

Aber warum es bei Benares auch nicht geht?

Hast du es mal intern versucht, ob es dort eine Fehlermeldung gibt?

sqlite3
.open /var/log/synolog/.SYNOCONNDB
DELETE FROM logs
VACUUM

 

[Shannachie]

Bei mir läuft das durch auf einer Kopie der Datei in meinem User-Home (44% free space von 3 TB); allerdings ohne Auswirkungen auf die Dateigröße.

 

[Benares]

Habs jetzt auch mal so probiert, wie vorgeschlagen.

sqlite3
.open /var/log/synolog/.SYNOCONNDB
DELETE FROM logs;
VACUUM;
.exit

Hat nichts gebracht.
Die .SYNOCONNDB ist bei mir nach wie vor ~1,5MB groß. Auf / (2,3GB) ist 60% genutzt.

Ich denke, da muss wohl doch mal Synology ran.

 

[Shannachie]

Ich reboote jetzt mal und hoffe auf innere Heilung über Nacht durch Cron oder andere Aufräum-Jobs, obwohl ich nicht wirklich daran glaube.
Parallel dazu habe ich mal ein Ticket über https://account.synology.com von der Leine gelassen:

The file .SYNOCONNDB under /var/log/synolog consumes 1,1GB of Space due to many SMB Failure entries.
Emptying the file with sqlite3 commands does not work, neither a "vacuum" command after trying to delete allt the entries in the database.

In the end the file still has its original and huge size.

The same result when executing the commands on a copy of the file in my user home.
Can I just delete the file from its original place on the running system without crashing the system?

Any help would be highly appreciated since this affects a number of services on my machine like backing up etc...

Ein herzliches Danke an alle, die sich hier schnell meines Problems angenommen haben. Ich schätze das sehr. ?
Ich gebe Euch Rückmeldung hier, wenn sich von Synology-Seite was getan hat.

Grüße
Alex.

 

[Benares]

Da bin ich ja mal gespannt. Ich habe es eben auch nochmal mit einer Kopie der DB probiert, die wurde durch das VACUUM etwas kleiner, aber nicht viel.

 

[Benares]

UUps, ich habe es gerade nochmal probiert. Und plötzlich ging es

root@DS415:/var/log/synolog# cp .SYNOCONNDB xxx
root@DS415:/var/log/synolog# sqlite3 xxx
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> delete from logs;
sqlite> vacuum;
sqlite> .exit
root@DS415:/var/log/synolog# ll .SYNOCONNDB xxx
-rw-rw---- 1 system log  1599488 Aug 23 17:41 .SYNOCONNDB
-rw-r----- 1 root   root    4096 Aug 26 18:14 xxx

 

[synfor]

Vermuteter Grund: Ich habe SMB1 erlauben müssen nach der Umstellung auf DSM 7, um die Syno-Shares wieder in Win 10 einhängen zu können.

Die Fehlermeldungen hast du aber nicht bekommen weil du SMB1 erlaubt hast. Damit hast du verhindert, dass das Log weiter mit diesen Einträgen geflutet wird. Die Einträge stammen aus der Zeit vor der Aktivierung von SMB1.

 

[Benares]

Das vermute ich auch. Jetzt geht es aber erstmal nur darum, die Log-DB nach Löschen der Einträge wieder geschrinkt zu bekommen.

 

[himitsu]

Eventuell hat ein anderer Prozess Zugriff und daher wird "noch" nichts freigegeben.

 

[Ramihyn]

Dumme Frage, aber wozu muss die Sonos überhaupt direkt aufs NAS zugreifen? Wäre es nicht sinnvoller, das über einen DLNA-Server zu lösen? Dann könntest du das Sicherheits-Scheunentor namens SMBv1 wieder verrammeln.

Den Tipp aus #2 greife ich sicherheitshalber mal auf; hab zwar weder SMBv1 im Einsatz noch ein Platzproblem in der Systempartition, aber Vorsicht hat auch eher selten geschadet.