Logs
Both services write their log files to var/log inside the installation directory, i.e. /opt/msh-zr/var/log. The directory is created automatically on the first service start, and all files are owned by the service user (msh by default). A typical listing looks like this:
drwxr-x--- 3 msh msh 4096 Jul 15 05:35 message-events
-rw-r----- 1 msh msh 94 Jul 15 04:36 milter.out
-rw-r----- 1 msh msh 160 Jul 15 05:35 milter.stats
-rw-r----- 1 msh msh 4492 Jul 15 05:35 msh-zr-milter.log
-rw-r----- 1 msh msh 1204 Jul 15 04:58 web.out
Launcher console output: milter.out and web.out
milter.out (milter service) and web.out (web service) capture everything the process prints to standard output and standard error. Each file is truncated when its service starts, so it only ever contains the output of the current (or most recent) run. The same lines also reach the systemd journal, so journalctl -u msh-zr-milter.service / journalctl -u msh-zr-web.service show identical content.
Look here for problems that occur before the application logging is up: launcher errors (missing or too old Java, invalid MSH_JAVA_BIN) and JVM startup failures.
Application log: msh-zr-milter.log
The main application log of the milter, written at info level with the format:
HH:mm:ss.SSS [thread] LEVEL logger - message
It records startup, connections from the Zimbra MTA, settings reloads from the shared database, and message processing errors. The file rolls over daily; rotated files are named msh-zr-milter.YYYY-MM-DD.log, the last 7 days are kept, and the total size of the rotated history is capped at 10 MB.
The web service does not write a separate application log file - its full output goes to the journal and web.out.
Worker pool statistics: milter.stats
A small snapshot of the milter's worker thread pool, rewritten at most once per stats update interval (STATS_UPDATE_TIME, default 60 seconds). It always contains the current values, one per line:
ActiveCount: 0
PoolSize: 10
CorePoolSize: 10
LargestPoolSize: 10
MaximumPoolSize: 10
TaskCount: 42
CompletedTaskCount: 42
CurrentQueueSize: 0
MaximumQueueSize: 20
ActiveCount- threads currently processing a message.PoolSize/CorePoolSize/MaximumPoolSize/LargestPoolSize- current, configured minimum, configured maximum and historical peak thread counts (POOL_SIZEin the configuration).TaskCount/CompletedTaskCount- messages submitted and finished since the service started.CurrentQueueSize/MaximumQueueSize- messages waiting for a free thread and the configured queue capacity (QUEUE_SIZE).
A CurrentQueueSize that keeps growing toward MaximumQueueSize means the milter cannot keep up with the mail volume - consider increasing the pool size (POOL_SIZE in etc/config.cf).
Message body dumps: message-events/
Event traces of processed messages (what the Events History page of the web UI displays) are stored in the shared SQLite database. When persisting message bodies is enabled in the diagnostic logging settings, the milter additionally stores the complete MIME message on disk, twice per message:
var/log/message-events/<date>/<id>-before.eml
var/log/message-events/<date>/<id>-after.eml
-before.eml- the message exactly as it arrived, before any rules were applied.-after.eml- the message after processing, as it was handed back to the MTA.
Comparing the two files shows precisely what the rules changed. The web UI reads these files from the same var/log directory and displays them in the Events History message details. Old events are pruned automatically together with their .eml files once they are older than the retention period configured in the diagnostic logging settings.
Because the web service reads the .eml files directly from the milter's var/log, both services must see the same directory. In the standard single-host installation this is always the case.
Additional resources
- Services - using these files to diagnose a service that does not start
- Events history - browsing processed messages in the web UI
- Diagnostic logging - enabling body persistence and setting the retention period