Demo
Demo

Knowledge base

PMTA knowledge base›Block <acct-file>›Directive§ 3.3.11.15

sync

<acct-file>

Whether to flush accounting records to disk regularly
in the configuration this is a linesync falseinside the block <acct-file>
What will be left in the file after a sudden reboot

Accounting records first land in operating system buffers and only then on disk. The line makes them flush regularly. The default is false.

The difference shows only in a crash. On a normal engine stop the buffers flush on their own. The line protects against the sudden — a power loss, a kernel panic, a hard reboot: without it the last records are lost, and the tail of the file may be corrupted.

The price is disk access. Under load accounting is written constantly, and regular flushing turns sequential writing into a series of forced disk accesses. On a node with a fast drive this is barely noticeable, on a slow one it is noticeable.

The main trap is turning it on “for reliability” without knowing why. Accounting is not messages: losing the last records means a gap in statistics, not lost mail. Weigh it against that, not against the cost of losing a message.
What the Hub does. It does not write it — flushing stays off.

🔎 We have an argument for this choice, and it is not about the disk: the main accounting stream goes through the webhook, that is, in batches once a minute. The most a crash can lose is an unfinished minute; everything else has already reached us and sits in the database. The file block is a safety net here, and there are no requirements for its tail.

In the main file the template also writes sync-msg-create false and sync-msg-update false — lines from the Protosender configuration that have nothing to do with accounting. The PowerMTA 6 manual has them neither in chapter 3 nor in the index; the nodes accept the lines. Their meaning comes from the comments of the sample configuration of earlier PowerMTA versions: flushing queued messages to disk after receipt and after handled recipients are marked. false is faster, but in a system crash a message not yet written to disk can be lost, and some recipients can get it again.

Recommended values

The decision depends on what the node is risking:

Value When
false (default) accounting goes out via webhook, or a gap in statistics is tolerable
true the accounting file is the only source, and the node has unreliable power
The false default and the purpose (protection against data corruption on system failure) come from the manual (§ 3.3.11.15). The analysis of the cost and the webhook argument are ours.
Example configuration
# the accounting file is the only source, and losing its tail is not acceptable
<acct-file /var/log/pmta/acct.csv>
    records d, b
    sync true</acct-file>
Where accounting goes out via webhook, the line makes less sense: the batches have already been sent, and at worst an unfinished minute will be lost.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Turning on flushing on a high-throughput node with a slow disk

our experience

What it costsSequential accounting writes turn into a series of forced disk accesses. At volume this is noticeable, while the gain is the safety of the last statistics records.
How to spot itAfter the edit, disk wait time went up.
How to do it rightWeigh it against the cost of loss: accounting is not messages. Where accounting goes out via webhook, the line is almost unnecessary.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
sync <boolean>
Values
yes | no | true | false
Default
false § 3.3.11.15
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<acct-file>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside its <acct-file> and concerns only its file. Different accounting streams can decide this differently — a safety-net file with flushing, a webhook one without.
⇄

Related directives

1 relation

Applies to

The telemetry contractDetermines how quickly this stream’s records get from memory to disk. § 3.3.11.15

How to check on the node
The value in force is visible only in the accounting block itself:
grep -n -A10 '<acct-file' /etc/pmta/config | grep -i 'sync\|acct-file'
No sync line in the block means false applies. The effect itself can only be checked by a crash, and that is not something to do on a working node.
◇

What else to read

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.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Five ways for a queue to hand off a messageA queue does not have to use SMTP: it can write to a file, run a program, call over HTTP or discard.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry
Neighboring settings of the block <acct-file>:record-fieldsrecordsiso-timesmap-header-to-fieldmove-toAll 26 directives of the block →