Knowledge base

retry-interval

<acct-file>

How often to restart the accounting receiver program after a failure
in the configuration this is a lineretry-interval 5minside the block <acct-file>
Only for accounting handed to a program

Accounting records can be handed not to a file but to a program — then the block tag has a vertical bar and a command instead of a path. This line sets how often to try to start the program again if a start failed. The default is 5m.

The line has nothing to do with files and webhooks. The manual stipulates this plainly.

The reason for it is more serious than it seems. The pipe form has a documented danger: on a failed write to the program the node gives up trying until a configuration reload or a timeout. This line is that timeout — without it a broken consumer would mean losing all accounting until manual intervention.

The vendor advises keeping a regular file alongside — precisely because the gap between a failure and a restart does not preserve data.

The main trap is believing a restart will save the data. It restores the flow, but records that fell into the gap are not saved anywhere. Only an accounting file block alongside saves them.
What the Hub does. It does not write it and does not use the pipe form: our accounting goes out via the webhook and is written to a file.

The line is worth recognizing when investigating someone else’s configuration: a pipe is a sign of a home-made statistics collector, and with it there are almost certainly losses the node owner does not know about.

Recommended values

The interval is sized to how much data you can afford to lose:

Value When
5m (default) the program rarely crashes
1m it crashes often, and every minute of data is valuable

And in any case — a file block alongside, otherwise the gap is lost entirely.

The 5m default and the fact that the line is only for the pipe form come from the manual (§ 3.3.11.6). The danger of loss in the gap and the advice to keep a file alongside come from § 12.1.1.
Example configuration
# pipe form: accounting is handed to a program
<acct-file |/usr/local/bin/collector.pl>
    retry-interval 1m    write-timeout 30s
</acct-file>

# and a file alongside — data for the gap between a failure and a restart
<acct-file /var/log/pmta/acct.csv>
    records d, b
</acct-file>
The second block is the vendor’s direct advice. Without it a program failure means a hole in the statistics that nothing can fill.
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 ends2 mistakes▶

Handing accounting to a program without a file alongside

§ 12.1.1

What it costsOn a failed write the node gives up trying until a restart or a timeout. Records for this gap are not saved anywhere.
How to spot itAfter the collector program restarts, there is a hole in the statistics.
How to do it rightSet up a second accounting block with a regular file — the vendor’s direct advice.

Setting the line for a file or webhook stream

§ 3.3.11.6

What it costsIt applies only to the pipe form. In other blocks it does nothing and misleads whoever reads the configuration.
How to spot itThe line sits in a block with a regular path or with a webhook address.
How to do it rightRemove it: for the webhook retries are built in, and for a file there are none.
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
retry-interval <time-interval>
Values
a time interval
Default
5m § 3.3.11.6
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
No inheritance: the line lives inside its own <acct-file> and applies only when this block hands records to a program.
How to check on the node
The engine writes program failures and restarts to its log:
grep -i "acct\|pipe" /var/log/pmta/log | tail -20
Repeated restart messages mean the program crashes and data in the gaps is lost. Fix the program, not the interval.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry