People, this week I have gone through a several iterations and
several degrees of Postfix-upstart integration.
The short answer is that only one option is practical at the moment.
The longer answer is summarized below.
Wietse
There are three major levels of Postfix-upstart integration.
- Boot-only integration: use upstart to start/stop Postfix at
boot/shutdown time and nowhere else.
This option is preferred. It requires no changes to Postfix,
and it does not affect Postfix reliability. Postfix comes
with its own daemon that (re)spawns mail processes as needed.
This small program has proven to be extremely reliable over
the past 14 years.
- Fake integration: this variant involves running a dummy process
directly under upstart. This program translates SIGHUP/SIGTERM
signals from upstart into postfix reload/stop commands.
This option has no benefits over "boot-only integration", as
observed by others; it just increases complexity. On the
positive side, it is fully compatible with existing Postfix
code for single-instance and multi-instance support.
- Full integration: all Postfix master daemons run directly under
upstart. This requires re-implementing the Postfix start/stop
commands and multi-instance provisioning commands, so that they
execute requests through initctl(8).
This option is not preferred. The code that executes requests
through initctl(8) needs to be maintained in parallel with
the existing management code, because many supported systems
do not use upstart. Another downside is that the longer code
paths through initctl(8) do not necessarily make Postfix more
reliable.
Unfortunately, a lot of energy has gone into debating the next
option on- and off-list:
- Broken integration: one proposed variant runs one Postfix master
daemon directly under upstart. It breaks the Postfix start/stop
commands and multi-instance support, because it lacks the steps
required for full initctl(8) integration (see previous item).
I tried several variants along this line. They were less broken,
but they still violated the principle of least astonishment.
I don't want to spend more words on this heated debate, except for
the following:
- If a new feature is important, then it should be developed in
the context of the Postfix development release, that is, Postfix
2.9.
- There is no need to distribute private branches of stable Postfix
releases that break major Postfix features.
