Grosse Caldav* Logfiles - housekeeping?

[TomH]

Hi Zusammen

Die Überwachung des Diskspaces meines Servers zeigte mir einen Alarm, dass der Speicherplatz auf / nur noch 20% freespace beträgt.

Ich habe etwas gesucht und gesehen, dass wohl die Caldav Logfiles viel Speicher belegen. Sicherlich auch deswegen, weil grosszügiges Logging eingeschaltet ist.

[root@mail files]# du -h */ | sort -hr
55G     groupdav/    

[root@mail files]# pwd -P   
/var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/info.XXXXXX.ch

[root@mail info.XXXXXX.ch]# ls -ltrah
total 32G
-rw-r--r--  1 33 tape 3.0K Nov  4  2019 iOS!13.2 (17B84) accountsd!1.0.log
-rw-r--r--  1 33 tape 6.0K Nov  4  2019 iOS!13.1.2 (17A860) accountsd!1.0.log
-rw-r--r--  1 33 tape 6.6M Nov 20  2019 iOS!13.1.2 (17A860) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 6.5M Nov 20  2019 iOS!13.1.2 (17A860) remindd!1.0.log
-rw-r--r--  1 33 tape  12M Nov 26  2019 iOS!13.2 (17B84) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  11M Nov 26  2019 iOS!13.2 (17B84) remindd!1.0.log
-rw-r--r--  1 33 tape 120M Dec 17  2019 CalDavSynchronizer!3.6.log
-rw-r--r--  1 33 tape  25M Dec 29  2019 iOS!13.2.3 (17B111) remindd!1.0.log
-rw-r--r--  1 33 tape  30M Dec 29  2019 iOS!13.2.3 (17B111) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  43M Mar  6  2020 iOS!13.3 (17C54) remindd!1.0.log
-rw-r--r--  1 33 tape  69M Mar  7  2020 iOS!13.3 (17C54) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  26M May 18  2020 iOS!13.3.1 (17D50) remindd!1.0.log
-rw-r--r--  1 33 tape  52M May 18  2020 iOS!13.3.1 (17D50) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 3.6G Jun  9  2020 CalDavSynchronizer!3.7.log
-rw-r--r--  1 33 tape  39M Jun 20  2020 iOS!13.4.1 (17E262) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  22M Jun 20  2020 iOS!13.4.1 (17E262) remindd!1.0.log
drwx------ 11 33 tape  242 Jul 22  2020 ..
-rw-r--r--  1 33 tape  20M Aug 17  2020 iOS!13.5.1 (17F80) remindd!1.0.log
-rw-r--r--  1 33 tape  38M Aug 17  2020 iOS!13.5.1 (17F80) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 9.8M Sep  1  2020 iOS!13.6 (17G68) remindd!1.0.log
-rw-r--r--  1 33 tape  16M Sep  1  2020 iOS!13.6 (17G68) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 6.0M Sep 10  2020 iOS!13.6.1 (17G80) remindd!1.0.log
-rw-r--r--  1 33 tape  12M Sep 10  2020 iOS!13.6.1 (17G80) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  44M Nov 29 09:27 iOS!13.7 (17H35) remindd!1.0.log
-rw-r--r--  1 33 tape  86M Nov 29 13:13 iOS!13.7 (17H35) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 3.8M Feb 10 05:50 iOS!14.3 (18C66) remindd!1.0.log
-rw-r--r--  1 33 tape 8.9M Feb 10 09:27 iOS!14.3 (18C66) dataaccessd!1.0.log
-rw-r--r--  1 33 tape  37M Mar 14 10:09 iOS!14.2 (18B92) remindd!1.0.log
-rw-r--r--  1 33 tape  80M Mar 14 18:20 iOS!14.2 (18B92) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 3.8M Mar 30 01:18 iOS!14.4 (18D52) remindd!1.0.log
-rw-r--r--  1 33 tape  12M Mar 30 01:22 iOS!14.4 (18D52) dataaccessd!1.0.log
drwx------  2 33 tape 4.0K Apr  2 21:08 .
-rw-r--r--  1 33 tape  15M Apr 11 19:18 iOS!14.4.1 (18D61) dataaccessd!1.0.log
-rw-r--r--  1 33 tape 7.6M Apr 11 19:18 iOS!14.4.1 (18D61) remindd!1.0.log
-rw-r--r--  1 33 tape 7.4M Apr 23 15:50 iOS!14.4.2 (18D70) remindd!1.0.log
-rw-r--r--  1 33 tape  27G Apr 23 20:53 CalDavSynchronizer!3.8.log
-rw-r--r--  1 33 tape  16M Apr 24 00:30 iOS!14.4.2 (18D70) dataaccessd!1.0.log

So habe ich mir überlegt, Logrotate konfigurieren um hier etwas Housekeeping zu betreiben.

Meine Frage an die Experten - können die älteren CalDavSynchronizer!x.y.log Dateien problemlos gelöscht werden?

Viele Grüsse
Tom

[StefanU]

Hi Tom.

Warum hast du (…) das Logging eingeschaltet?

Wir haben hier zumindest auf die Gefahr hingewiesen:

Zugriff auf EGroupware per WebDAV (CalDAV/CardDAV)

Ich muss da wohl noch etwas nachbessern…

---

Wenn du dir in EGw das Log anschaust, gibt es da einen Button zum Löschen des Loggings/des Logs. Kannst das ja mal ausprobieren. Das sollte auch die Datei komplett löschen(?).

Wenn dem so ist:

können die älteren CalDavSynchronizer!x.y.log Dateien problemlos gelöscht werden?

Ja.

Stefan

[TomH]

Morgen Stefan

Danke für deine Rückmeldung!

Warum hast du (…) das Logging eingeschaltet?

Ich hatte mal zwei Themen wo ich das Logging gebraucht hatte. Hier und hier. Ich habe damit gerechnet, dass ich es bald wieder brauchen würde. Das war dann nicht der Fall, aber ich habe es aktiviert gelassen, für den Fall dass ich weiter ‘reindiggen’ müsste und es einem Anwender einfacher machen kann wenn ein Problem auftreten sollte.

Wir haben hier zumindest auf die Gefahr hingewiesen:

Ok - ja, Full Logging heisst immer grosse Files

Wenn du dir in EGw das Log anschaust, gibt es da einen Button zum Löschen des Loggings/des Logs. Kannst das ja mal ausprobieren. Das sollte auch die Datei komplett löschen(?).

Cool, ich teste das.

können die älteren CalDavSynchronizer!x.y.log Dateien problemlos gelöscht werden?

Ja.

Danke dir und viele Grüsse,
Tom

[StefanU]

Nachtrag: Ich habe das Kapitel etwas ergänzt. Die Hilfe in den Einstellungen mache ich noch.
Stefan

[TomH]

Hallo Stefan / Alle

Nachtrag: Ich habe das Kapitel etwas ergänzt.

Danke!
Ich habe noch den Versuch gemacht, Logrotate einzurichten. Meine lograte config:

[root@mail logrotate.d]# cat /etc/logrotate.d/groupdav
'/var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/**/*.log' {
    weekly
    rotate 5
    size 250M
    compress
}

Der Fehler:

[root@mail logrotate.d]# logrotate -dvf /etc/logrotate.d/groupdav
(..)
rotating log /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log, log->rotateCount is 5
dateext suffix '-20210424'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.5.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.6.gz (rotatecount 5, logstart 1, i 5), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.4.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.5.gz (rotatecount 5, logstart 1, i 4), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.3.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.4.gz (rotatecount 5, logstart 1, i 3), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.2.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.3.gz (rotatecount 5, logstart 1, i 2), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.1.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.2.gz (rotatecount 5, logstart 1, i 1), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.0.gz to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.1.gz (rotatecount 5, logstart 1, i 0), 
renaming /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log to /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.1
compressing log with: /bin/gzip
removing old log /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.6.gz
error: error opening /var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/XXXXXX/Mozilla!5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko!20100101 Thunderbird!68.8.0 Lightning!68.8.0.log.6.gz: No such file or directory
(..)

Ich habe das Gefühl, dass diese Spezialzeichen “!”, “(”, “)” “;”, " " in den Dateinamen der Logfiles ein Showstopper für Logrotate sind.

Hier lese ich:

So you have to escape the space with you do with quotes, but your wildcard causes a problem. For the wildcard to work it must be outside the quotes.

Dann ein paar Beispiele wir man dies umgehen kann, jedoch nur für Shell-Scripts und nicht für Logrotate explizit. Aber gut, beim erstellen von Shell-Scripts ist mir der Umgang mit diesen Spezialzeichen klar.

Ich versuche ein Shell-Script zu schreiben, welches das Housekeeping machen kann. Wenn das jemand mit Logrotate hinbringen würde, wäre mir das am sympathischsten.

Ich poste das eingesetzte Shell-Script hier, wenn es fertig ist.

Viele Grüsse
Tom

[RalfBecker]

Generell macht Logrotate relativ wenig Sinn, da mit jedem Update des CalDAV Clients sich dessen USER_AGENT ändert, da er die Versionsnummer beinhaltet und damit sicher der Dateinamen ändert.

Vermutlich sinnvoller alle Dateien löschen, in die seit ein paar Tagen bzw. Wochen nix mehr geschrieben wurde.

Ralf

[TomH]

Hi Ralf

da mit jedem Update des CalDAV Clients sich dessen USER_AGENT ändert

Damit würde Logrotate theoretisch ja umgehen können, wenn man mit den Wildcards arbeitet.

‘/var/lib/docker/volumes/egroupware-docker_data/_data/default/files/groupdav/**/*.log’

sinnvoller alle Dateien löschen, in die seit ein paar Tagen bzw. Wochen nix mehr geschrieben

Got it, thanks! PS: Wobei, wenn der Client (CalDAV Synronizer in diesem Fall) nicht upgedated wird, dann wird ja immer in das selbe File geschrieben. Darum ist ja wohl auch CalDavSynchronizer!3.8.log 27GB gross.

Ich denke logrotate (oder ein selber gemachtes equivalent) wäre schon das richtige, damit würden diese 27GB files nicht entstehen. Für die anderen Files wäre das schlichte löschen ab einem bestimmten Alter sicher dann das richtige. Wobei würde logrotate damit umgehen können, hätte man alle Logfiles auf einen Streich gleich mit-erledigt.

Gruss,
Tom

[TomH]

Wie versprochen hier noch mein Script und die logs zu rotieren.

rotate-groupdav.sh.txt (3,1 KB)

Und noch die crontab von root:

[root@mail scripts]# crontab -l
(..)
# Rotate logs in groupdav folder of eGroupware
0 0 1 * * /root/scripts/rotate-groupdav.sh >> /var/log/rotate-groupdav.log 2>&1

Vg
Tom