ZCS Administrator's Guide 8.0.4
ZCS Administrator's Guide 8.0.4
Open Source Edition

Monitoring ZCS Servers > Viewing Log Files

Viewing Log Files
ZCS logs its activities and errors to a combination of system logs through the syslog daemon as well as Zimbra specific logs on the local file system. The logs described below are the primary logs that are used for analysis and troubleshooting.
Local logs containing Zimbra activity are in the /opt/zimbra/log directory.
audit.log. This log contains authentication activity of users and administrators and login failures. In addition, it logs admin activity to be able to track configuration changes.
clamd.log. This log contains activity from the antivirus application clamd.
freshclam.log. This log contains log information related to the updating of the clamd virus definitions.
mailbox.log. This log is a mailboxd log4j server log containing the logs from the mailbox server. This includes the mailbox store, LMTP server, IMAP and POP servers, and Index server.
myslow.log. This slow query log consists of all SQL statements from the mailbox server that took more then long_query_time seconds to execute. Note: long_query_time is defined in /opt/zimbra/conf/my.cnf.
spamtrain.log. This log contains output from zmtrainsa during regularly scheduled executions from the cron.
sync.log. This log contains information about ZCS mobile sync operations.
Other logs include:
/opt/zimbra/jetty/logs/. This is where Jetty-specific activity is logged.
/opt/zimbra/db/data. <hostname>.err. This is the message store database error log.
/opt/zimbra/logger/db/data. <hostname>.err. This is the Logger database error log.
ZCS activity logged to System syslog
/var/log/zimbra.log. The Zimbra syslog details the activities of the Zimbra MTA (Postfix, amavisd, antispam, antivirus), Logger, Authentication (cyrus-sasl), and Directory (OpenLDAP). By default LDAP activity is logged to Zimbra.log.
Zimbra modifies the systems syslog daemon to capture data from the mail and local syslog facility to /var/log/zimbra.log. This allows syslogd to capture data from several ZCS components including Postfix, Amavis, ClamAV, mailboxd, zmconfigd, and logger. The SNMP module uses the data from the log file to generate traps for critical errors. The zmlogger daemon also collects a subset of the data in this file to provide statistics on the utilization of ZCS via the administration console.
By default, mailboxd is configured to log its output to /opt/zimbra/log/mailbox.log. You can enable mailboxd to take advantage of a centralized syslogd infrastructure by enabling the following either globally or by server
zmprov mcf zimbraLogToSysLog True
Use log4j to Configure Logging
The ZCS server uses log4j, a Java logging package as the log manager. By default, the ZCS server has log4j configured to log to the local file system. You can configure log4j to direct output to another location. Go to the Log4j website for information about using log4j.
ZCS does not check the log4j changes. To remove all account loggers and reloads in /opt/zimbra/conf/log4j.properties, use the zmprov resetAllLoggers command.
Logging Levels
The default logging level is set to include logs that are generated for INFO, WARNING, ERROR and FATAL. When problems start to occur, you can turn on the DEBUG or TRACE log levels.
To change the logging levels, edit the log4j properties, log4j properties, log4j.logger.zimbra.
When enabling DEBUG, you can specify a specific category to debug. For example, to see debug details for POP activity, you would type logger.zimbra.pop=DEBUG.
The following categories are predefined in log4j:
Changes to the log level take affect immediately.
Logging Levels
Table 2:  
Protocol Trace
Protocol trace is available in the following logging categories:
Review mailbox.log Records
The mailbox.log file contains every action taken on the mailbox server, including authentication sessions, LMTP, POP3, and IMAP servers, and Index server. Review the mailbox.log to find information about the health of your server and to help identify problems.
Mailbox.log records valid and invalid login attempts, account activity such as opening email, deleting items, creating items, indexing of new mail, server activities including start and stop. The progress of an activity on the mail server is logged as INFO. If the expected results of the activity fails and errors occurs, an exception is written to the log.
You can set up logging options for a single account in order to trace account activity for one user without filling up mailbox.log with log messages for unrelated accounts. See Appendix A Command-Line Utilities, the zmprov miscellaneous section.
Reading records in the log
The example below is a record showing that on June 25, 2007, the zimbra server with an IP address of was in the process of deleting backups that were created on Monday, June 18, 2007 at 8 seconds after midnight Pacific Daylight Time (PDT) or older than that date.
Component thread number identifies which thread managed by mailboxd is performing the action logged.
Handler Exceptions and Stack Traces
If an error occurs during the progress of an activity, a handler exception is added to the end of the log record to notify you that an event occurred during the execution of the process that disrupted the normal flow. This signals that some type of error was detected.
Sometimes a stack trace is displayed after the exceptions notification. A stack trace reports the threads and monitors in the zimbra’s mailboxd service. This information aids in debugging, because the trace shows where the error occurred. The last few entries in the stack often indicate the origin of the problem. When the caused by descriptor is included in the log line, this is the root of the error. In the example below, the error was caused by 501, bad address syntax.
at com.example.cs.mailbox.MailServiceException.internal_SEND_FAILURE (MailServiceException.java:412)
at com.example.cs.mailbox.MailServiceException.SEND_ABORTED_ADDRESS_ FAILURE MailServiceException.java:416)
Caused by: com.example.cs.mailbox.MailSender$SafeSendFailedException :501 Bad address syntax
Mailbox log files
The mailbox.log files rotate daily. The mailbox log files are saved in /opt/zimbra/log. Previous mailbox.log file names include the date the file was made. The log without a date is the current log file. You can back up and remove these files.
Troubleshoot Mail Problems
To review the mailbox.log for errors, search for the email address or the service that is experiencing the problem. Also, search for WARN or ERROR log levels, read the text of the message. When you find the error, review the records, tracing the events that happened before the problem was recorded.
System Crashing
When your system crashes, locate the startup message and then look for errors before the startup message date. This example shows an out-of-memory error on June 17, 2007.
Look for errors before the startup message.
Mail Delivery Problem
Locate the “LmtpServer” service. This example includes a stack trace report with a caused by explanation that the recipient address was rejected as the address must be a fully-qualified address.
2007-06-25 10:47:43,008 INFO [LmtpServer-250] [name=bigen@example.com;mid=30;msgid=<1291804360.35481182793659172.JavaMail.root@dogfood.example.com>;] lmtp - rejecting message bigen@example.com: exception occurred
Caused by: com.zimbra.cs.mailbox.MailSender$SafeSendFailedException: 504 <too>: Recipient address rejected: need fully-qualified address
Account Error- Log in error
Mailbox.log logs any successful or unsuccessful login attempts from IMAP, POP3 or ZWC. When you are looking for a login error, start by looking for “Auth.” This example shows that someone from IP address was trying to log in as admin on the Zimbra Web Client, using Firefox in a Windows OS. Permission was denied because it was not an admin account.
Account Errors - IMAP or POP related
When you are looking for a log because of an IMAP or POP issue, look for “ImapServer/Pop3Server.” This example shows a fatal IMAP server error occurred while trying to connect siress@example.com.
Copyright © 2013 VMware Inc.