Hi everybody, we have discovered that our /opt/zimbra/log folder is weighted by two log files:
YYYY_MM_DD.trace.log
access_log.YYYY-MM-DD
That are created every day, but not compressed, so about 280Mb are occupied every day.
There is a bug report about this ( https://bugzilla.zimbra.com/show_bug.cgi?id=63661 ), that says that those files are created by jetty and not affected by logrotate (in fact there are no references to those log files in /etc/logrotate.d/zimbra) but their creation is ruled by /opt/zimbra/jetty/etc/jetty.xml, that does not specify compression or rotation. Does anybody know how to normally rotate those logs? An user on that bug reporting just suggests to add two crontab rules as a workaround.
YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD
-
- Outstanding Member
- Posts: 284
- Joined: Sat Sep 13, 2014 1:55 am
- ZCS/ZD Version: 8.8.15_FOSS Patch38
YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD
Has anyone tried to edit jetty.xml file?
/../log/access_log.yyyy_mm_dd
dd/MMM/yyyy:HH:mm:ss Z
30
true
true
yyyy-MM-dd
true
Maybe could be set to "false"
In zimbra.web.xml.in there is also
logVerbosityLevel
DEBUG
that maybe can be reduced to WARN...
/../log/access_log.yyyy_mm_dd
dd/MMM/yyyy:HH:mm:ss Z
30
true
true
yyyy-MM-dd
true
Maybe could be set to "false"
In zimbra.web.xml.in there is also
logVerbosityLevel
DEBUG
that maybe can be reduced to WARN...
Re: YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD
crontab -l -u zimbra | grep -i log
in /opt/zimbra/libexec/zmcompresslogs seems that we haven't compress of apache access logs and trace logs
Code: Select all
# Log pruning
30 2 * * * find /opt/zimbra/log/ ! -name 'zmsetup*.log' -type f -name '*.log?*' -mtime +8 -exec rm {} \; > /dev/null 2>&1
35 2 * * * find /opt/zimbra/log/ -type f -name '*.out.????????????' -mtime +8 -exec rm {} \; > /dev/null 2>&1
# compress logs manually to avoid application pauses when
# handled through the log4j thread
50 2 * * * /opt/zimbra/libexec/zmcompresslogs > /dev/null 2>&1
# Status logging
*/2 * * * * /opt/zimbra/libexec/zmstatuslog > /dev/null 2>&1
#*/10 * * * * /opt/zimbra/libexec/zmdisklog > /dev/null 2>&1
# Log pruning
30 2 * * * find /opt/zimbra/mailboxd/logs/ -type f -name \*log\* -mtime +8 -exec rm {} \; > /dev/null 2>&1
30 2 * * * find /opt/zimbra/log/ -type f -name stacktrace.\* -mtime +8 -exec rm {} \; > /dev/null 2>&1
# Invoke "client_usage_report.py" periodically to process /opt/zimbra/log/access_log* files
-
- Posts: 1
- Joined: Thu Jan 20, 2022 1:39 pm
Re: YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD
I simply created a rotate in zimbra user crontab for this case:
# ZIMBRAEND -- DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZIMBRASTART
#
#Gzip Logs
30 6 * * * gzip /opt/zimbra/log/trace_log.$(date -d 'yesterday' +%Y_%m_%d) > /dev/null 2>&1
50 6 * * * gzip /opt/zimbra/log/access_log.$(date -d 'yesterday' +%Y-%m-%d) > /dev/null 2>&1
#
# ZIMBRAEND -- DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZIMBRASTART
#
#Gzip Logs
30 6 * * * gzip /opt/zimbra/log/trace_log.$(date -d 'yesterday' +%Y_%m_%d) > /dev/null 2>&1
50 6 * * * gzip /opt/zimbra/log/access_log.$(date -d 'yesterday' +%Y-%m-%d) > /dev/null 2>&1
#