Hi!
06.12.2024 12:10, Raphael Hertzog wrote:
On Wed, 04 Dec 2024, Michael Tokarev wrote:
I filed https://bugs.debian.org/1088862 adding you to Cc, but apparently
did that incorrectly, so now I'm relying this bugreport to you. It would
be nice if you give some comments about this matter, since apparently it
was you who implemented postmulti setup for the debian postfix package
at that time.
We did get a copy of the initial bug report and saw it, you didn't do any
mistake. However that implementation dates back to 2016 and I don't
remember the various advantages/drawbacks of the various options, and
the available features in systemd were certainly different at that time.
I think systemd part hasn't changed much, at least in the areas actually
used by postfix setup.
However you might want to consider what I said here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849584#30
Yes, it's the same concerns which bothers me and which has been confusing
to the users as well - using postfix@-.service for a common setup like
some 99.99% people use, just to allow the remaining 0.01% to have more
advanced functionality - and we don't even know if these 0.01% exists :)
It's not obvious that having two service units make things "easier". But
if in the mean time there are upstream recommendations or a pattern that
has been used by multiple other distributions, then it might be worth
reevaluating the choice.
I don't think many people actually use multi-instance postfix setup to
begin with. It's a quite niche thing. And from that niche, using system
or not is a moot question, since these users has their own requirements,
unique in each case.
While thinking about it further, I found a more interesting solution which
*might* suit everything (or almost), -- see below.
On wast majority of systems, there's just one postfix instance running.
However, with default-to-multi on debian, the expected thngs like
`journalctl -u postfix` or `systemctl status postfix` does not quite
work, because these shows the "dummy" all-multi service which does
nothing - actual service is postfix@-. This is unexpected, difficult
to find, and annoying.
I sort of agree with that.
For the same reason, it's difficult to override systemd settings for
the service if needed (eg, bind-mounting extra stuff to a chroot, or
whatever else might be needed locally - with chroot setup being the
default such need comes more often).
But not with that. It's not more difficult, you just need to use the right
service unit.
It's the same confusion as using `journalctl -u postfix@*' vs a normal
and expected `-u postfix', ditto for systemctl status etc.
What I'm thinkng is to ship plain, simple postfix.service (and the
init.d script) which does just regular `postfix start|stop|reload`.
This will work for (simple) multi-instance postfix setups too by
the "magic" already existing in postfix (`postfix start` etc applies
to whole set of configured instances). This will restore the strange
`postfix@-` naming back to the usual and expected `postfix` naming,
and will allow upstream-managed multi-instance config to work.
That seems appealing to me. I don't know if that magic behaviour of
postfix is something that appeared in the mean time or if I just wasn't
aware of it.
However you lose the possibility to customize systemd-level settings
for each instance. The settings would be shared for all instances and they
would be all started/stopped together.
This is why I want a choice: either manage whole thing the postfix way
using single service and single custom settings (if that ever needed at
all), or allow to split things up into separate, systemd-managed, units
with individual settings for each.
I don't know if that's acceptable or not. While we implemented this
feature as part of implementing systemd support, we have never used a
complex setup with multiple instances except for validating this work.
Yeah, we're in the same boat here: we don't know how it's actually used
in practice when big multi-instance setup is actually needed.
Maybe, with a little modification to postmulti binary (should be
discussed with upstream), such simple `postfix.service` can be
seen as a multi-part service in systemd too - eg, it's possible
to modify postmulti not to run an instance directly by running
`postfix start` command for it, but to use something like
`systemd-run --part-of postfix --- postfix start` -- this might
even be possible now by setting the appropriate multi_instance_wrapper
parameter.
If we accept the above tradeoff of managing all instances in a single
unit, it certainly makes sense to try to inject any manually started
instance into the global postfix unit and such a change would then make
sense.
Note that I don't see the "--part-of" option in "man systemd-run" (on
unstable). Are you sure that we can do something like this?
That's just an imaginary thing, I don't remember if such feature exists -
I mean to make a transient unit being part of another unit.
But meanwhile, I've the following idea.
How about making the default/main instance to be really special - controlled
by regular postfix.service (in other words, do not make it dummy as it now
is, but return actual functionality to it).
The setup looks like:
1. Make a choice, to use multi-instance setup EITHER postfix-way or systemd-way,
using a flag/file, an environment variable (in /etc/default/postfix) or
something.
2. postfix.service becomes regular, non-dummy, service, which runs
/usr/share/postfix/postfix-startup-helper instead of postfix or postmulti.
Which, in turn, run EITHER `postfix start' for the whole thing, OR a single
default instance like `postmulti -i - start', depending on this setting.
3. In case systemd-way multi-instance setup is enabled,
postfix-instance-generator
is run creating instances of postfix@.service, for everything BUT the
default instance (so there's no special handling for - in there).
The only difference here is that all other instances becomes dependent on the
default instance, - default instance can not be restarted or stopped without
all other instances being stopped too. I don't know if this is good or bad.
If this is bad for a certain site, I guess we can provide an alternative,
dummy postfix.service which we ship now, so they can replace default
postfix.service with this dummy one.
What do you think?
Thanks,
/mjt
