Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.105

track-jobs

<domain>

Whether to show the receiver's jobs on the monitor page
in the configuration this is a linetrack-jobs falseinside the block <domain>
Queue breakdown by mailing

The line enables counting jobs for a specific receiver. With the line on, jobs associated with this receiver appear on its detailed page in the web monitor. The default is false.

A job is a mailing from the engine’s point of view: messages submitted with one job identifier. The line answers the question “which mailings exactly are queued for this receiver”, not “how many messages in total”.

The value lives only in the monitor. The job identifier is in accounting even without this line — as the jobId field; this is about the queue breakdown, which the monitor will not show without it.

The line is per receiver, not per node. It makes sense to enable it where a queue builds up: at one or two large receivers, not in the asterisk block.

The main trap is enabling it in the asterisk block. Job counting will be done for all receivers at once, while each has its own monitor page — the benefit is exactly the same, and the node’s work is several times greater.
What the Hub does. It does not write it: we do not use the monitor pages, and we build the breakdown by mailing from accounting — the job identifier field is in every record there.

The line will come in handy for someone investigating on the node by hand who wants to see which mailing holds the queue at a specific receiver.

Recommended values

Enabled pointwise, at a problem receiver:

Value When
no (default) always
yes at one receiver a queue builds up there and you need to understand whose mailing it is
yes in <domain *> almost never
The false default and the fact that jobs appear on the receiver’s detailed page in the monitor come from the manual (§ 3.3.10.105). The advice to enable it pointwise is ours.
Example configuration
# a queue is building up at this receiver — we want to see whose mailing it is
<domain yahoo.com>
    track-jobs yes</domain>
In <domain *> the same line enables counting for all receivers at once — several times more work, the same benefit.
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▶

Enabling it for all receivers at once

our experience

What it costsCounting is done for every receiver, while people look at one page. The node’s work grows in proportion to the number of receivers with no benefit.
How to spot itThe line sits in the asterisk block.
How to do it rightLimit it to a specific receiver’s block; remove it after the investigation.

Looking here for the job identifier for accounting

our experience

What it costsThe job field is in the accounting record even without this line. It is about the queue breakdown in the monitor, not about record composition.
How to spot itThe line was enabled for the sake of a field in accounting, but the field was there before.
How to do it rightFor accounting look at record-fields; this line is only about the monitor.
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
track-jobs <boolean>
Values
yes | no | true | false
Default
false § 3.3.10.105
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <domain> and merges by the usual rule of receiver blocks: the most exact match by receiver name wins. The same three levels apply by sending address.
⇄

Related directives

1 relation

Depends on

process-x-job<source>The job identifier comes from there — without it there is nothing to break the queue down by. § 3.3.10.105

How to check on the node
The result is visible on the receiver’s page in the monitor; from the console the same is shown by a request for it:
curl -s 'http://NODE:1000/domains?format=json' | head -c 400
The job list will appear in the receiver’s details. Nothing with the line on means there are currently no jobs queued for it.
◇

What else to read

3 articles

◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇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.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Bounce classification · Tune the pace for a provider
Neighboring settings of the block <domain>:connect-timeoutauth-usernamecommandallow-cancel-during-transferassume-delivery-upon-data-termination-timeoutAll 135 directives of the block →