Demo
Demo

Knowledge base

PMTA knowledge base›Procedure§ 4.1.3

Starting and stopping the engine

PowerMTA startup and shutdown
Delivery stops, not the messages

The engine is started by the platform’s standard means: as a service on Windows, with a startup script on Unix.

After start there must be two processes. The engine itself and the watchdog that brings it back up after a crash (pmtawatch). If there is no watchdog, the node loses the ability to get back up on its own — and this can only be noticed by checking.

A stop halts delivery but does not touch the messages. They lie in the spool on disk and are picked up at the next start. So a stop is safe for mail and dangerous only for deadlines: messages age, and the bounce deadline keeps running.

A start with a wrong configuration does not go through. The engine does not take the “last working” one and does not start with defaults — it simply does not come up, and writes the reason to a separate file (startup-error-log).

The main trap is stopping the node and forgetting the bounce deadline. Messages in the spool survive the stop, but their deadline keeps running: a node that stood still longer than the bounce deadline will come back to a queue part of which can no longer be delivered — it will bounce on deadline right after the start. A short stop is harmless, a many-hour one is not.
What the Hub does. It applies edits with a settings reload, which does not interrupt delivery (config-reload). The engine service can be stopped, started and restarted from the cabinet — the “Control” section, the “Stop engine service”, “Start engine service” and “Restart engine service” buttons: the Hub runs systemctl on the node over SSH and checks that the service reached the expected state.

On its own the Hub does not restart the service — and its templates contain no directives that require a service restart. The web monitor’s lines require a monitor restart, and the Hub does that itself after every apply.

⚠️ Checking that the watchdog came up together with the engine remains manual: telemetry only has the engine itself.

Recommended values

What to remember about a stop:

What How it behaves
messages in the queue stay on disk, are picked up at start
bounce deadline keeps running while the node is down
incoming connections are not accepted, the submitting side gets a rejection
watchdog must come up together with the engine — check

Match the length of a stop to the bounce deadline. Downtime of a quarter of the deadline is harmless; downtime longer than the deadline means part of the queue will bounce right after the start.

Warn the submitting side. While the node is down, platforms get a rejection at submission — and what they do with it is up to them.

The analysis of behavior during a stop and the advice to match it to the deadline are ours. From the manual come the ways to start on both platforms, the requirement to check for the watchdog and the fact that messages stay on disk.
Example configuration
# after start there must be two processes
/etc/init.d/pmta start
ps -ef | grep -E '[p]mtad|[p]mtawatch'
The highlighted line is exactly the check that is skipped most often. One process instead of two means the node has lost the ability to get back up after a crash on its own.
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 ends3 mistakes▶

Stopping the node for longer than the bounce deadline

§ 4.1

What it costsMessages survive the stop, but their deadline keeps running. A node that stood still longer than the bounce deadline will come back to a queue part of which will bounce on deadline right after the start.
How to spot itRight after the start, a burst of bounces on expired deadlines, while the receivers are fine.
How to do it rightMatch the length of a stop to the bounce deadline. For configuration edits use a reload — it does not interrupt delivery at all.

Not checking whether the watchdog came up

§ 4.1

What it costsThe node works but loses the ability to get back up after a crash on its own. This is discovered at the first crash — that is, exactly when the node simply stays down.
How to spot itOne process instead of two; the node did not come back after a failure.
How to do it rightCheck both processes after every start.

Expecting the node to start on defaults with a broken configuration

§ 4.2.1

What it costsIt does not start at all. The engine does not take the last working configuration and does not substitute defaults — it stops and writes the reason to a separate file.
How to spot itAfter a configuration edit the node does not come up; in the summary it is unavailable.
How to do it rightCheck parsing before starting. On failure, read the startup error file, not the main log.
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.
⇄

Related entries

3 relations

Does not work without

The watchdog that restarts the engineA manual stop and start is the same action the watchdog performs by itself after a crash. § 4.1.3

Can be replaced by

Reloading settings versus restarting the serviceA settings reload does the same as a restart, but without stopping delivery. inference

Affects

Running without root privilegesChanging the user is one of the few edits that cannot avoid a stop. § 4.1.3

Referenced from

What to do after a crashA related procedure: they share some of the steps. inferenceSpool reading at startupThe part of startup that takes time, and the only sign that it has finished. § 5.3Apply a changed configuration without stoppingThe heavy way of applying — with sending stopped; only a few directives need it. § 6.3.5Switching over to a standby nodeA related procedure: they share some of the steps. § 11.11

How to check on the node
The check after start — three questions in a row:
ps -ef | grep -E '[p]mtad|[p]mtawatch'
pmta show status
The first answers whether the watchdog came up. The second shows that the engine is running, when it was started and how many recipients are in the queues: if the stop was long, some messages will bounce on expiry right after the start.
◇

What else to read

3 articles

◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇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.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.

In the Hub
Cost of a mistake
disruptive: applying it interrupts the node
Scenarios
Configuration lifecycle · Emergency stop