YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
7224jobe
Outstanding Member
Outstanding Member
Posts: 283
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

Post by 7224jobe »

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.
7224jobe
Outstanding Member
Outstanding Member
Posts: 283
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

Post by 7224jobe »

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...
sergiomb
Posts: 8
Joined: Sat Feb 01, 2020 4:10 am

Re: YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD

Post by sergiomb »

crontab -l -u zimbra | grep -i log

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
in /opt/zimbra/libexec/zmcompresslogs seems that we haven't compress of apache access logs and trace logs
sergiomb
Posts: 8
Joined: Sat Feb 01, 2020 4:10 am

Re: YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD

Post by sergiomb »

condealisson
Posts: 1
Joined: Thu Jan 20, 2022 1:39 pm

Re: YYYY_MM_DD.trace.log and access_log.YYYY-MM-DD

Post by condealisson »

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
#
Post Reply