Global
The line adds milliseconds to the timestamp: instead of 2026-08-28 15:54:31 the log shows 2026-08-28 15:54:31.593. The default is false.
The point is not precision but order. Within one second an ordinary timestamp does not distinguish events, and when investigating a race — which came first, the connection or the configuration reload — the log stops answering the question.
The price is a few bytes per line and a slightly noisier log when read by eye.
The line does not affect accounting — there the timestamp format is set separately, via iso-times in the <acct-file> block.
The line would come in handy when investigating a rare class of faults: when you need the order of events within a second — for example, whether applying the configuration managed to close a connection before the receiver took it.
Enabled for a specific investigation:
| Value | When |
|---|---|
| false (default) | always |
| true | investigating the order of events within a second |
# investigating a race: who came first within one second log-file /var/log/pmta/log log-hires-timestamp true
what people get wrong and how it ends1 mistake▶
our experience
1 relation
tail -2 /var/log/pmta/log
3 articles
◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇What makes a virtual machine riskyRunning on a virtual machine is possible, but the manual does not recommend it without sufficient hardware and properly tuned hypervisor settings: under load the node may stop responding.