Knowledge base

write-timeout

<acct-file>

How long to wait for the receiver program when writing
in the configuration this is a linewrite-timeout 1minside the block <acct-file>
So that someone else’s program does not hold up the mail node

The line limits waiting when writing to the program that accounting records are handed to. The default is 1m, and it applies only to the pipe form.

The point is in one word — “unresponsive”. A collector program may not crash but simply stop reading: hang, get stuck on its database, go into an endless loop. Without a threshold the node would wait for it indefinitely, and accounting would hold up mail.

The threshold and the restart are a pair. This one limits a single write, retry-interval schedules the next attempt after a failure.

A minute is a lot. For a mail node a one-minute pause on writing accounting is noticeable, and under load the threshold is usually lowered.

The main trap is taking the default for a safe value. A minute per write with a hung collector adds up to a noticeable delay. If the collector is your own and fast, the threshold is worth lowering to seconds.
What the Hub does. It does not write it and does not use the pipe form.

We follow the same principle elsewhere: the telemetry receiver replies at once and parses the batch in the background — precisely so as not to hold up someone else’s mail node. Here the threshold solves the same task from the node’s side.

Recommended values

The threshold is sized to the collector’s speed:

Value When
1m (default) the collector belongs to someone else, its behavior is unknown
5s–10s the collector is your own and fast

A write failure does not lose data silently — it triggers the restart mechanism, but the gap is still not saved.

The 1m default and the purpose (not letting an unresponsive application hold up the node) come from the manual (§ 3.3.11.9). The advice to lower the threshold for your own collector is ours.
Example configuration
# your own fast collector — a threshold in seconds, not a minute
<acct-file |/usr/local/bin/collector.pl>
    write-timeout 10s    retry-interval 1m
</acct-file>
The two lines work as a pair: the first breaks off a hung write, the second schedules the next attempt.
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▶

Raising the threshold instead of speeding up the collector

our experience

What it costsThe node waits longer, and accounting starts to affect mail sending. The cause — synchronous processing in the collector — remains.
How to spot itThe threshold has already been raised twice, and each time it helped only briefly.
How to do it rightRewrite the collector: accept the record, reply, process in the background.
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
write-timeout <time-interval>
Values
a time interval
Default
1m § 3.3.11.9
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 threshold failures to its log:
grep -i "timeout" /var/log/pmta/log | tail -20
Regular failures mean the collector cannot keep up. Raising the threshold is a temporary measure; it is better to make it accept quickly and process in the background.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Collect telemetry