On 11/20/25 22:58, David Mandelberg wrote:
Op 2025-11-20 om 02:49 schreef Michael Tokarev:
I probably can add WantedBy=postfix.service into [email protected],
but this will make all instances inter-dependent (they already
sort of are, due to PartOf=postfix.service).
That would work for me because I want all of my postfix instances to be
running. How would it work when an instance is disabled or masked though?
There's no such thing as disabled/masked instances. You enable
an instance in systemd explicitly, which creates multi-user.wants.d/
symlink, - only if there, systemd will start it. Current setup does
not use in-postfix list of instances (anymore).
There's a prob with this approach though: the user has to re-enable
their instances again once another WantedBy is added (so the particular
instance is added to postfix.service.wants.d/). And I yet to find a
solution for that.
Btw, why did you lower the priority? This bug means that upgrades
completely break all non-default instances without manual intervention,
which makes it unsafe to automatically apply security updates.
Because it is what it is: "a bug that does not undermine the usability
of the whole package; for example, a problem with a particular option
or menu item" (normal), not "a bug which has a major effect on the
usability of a package, without rendering it completely unusable to
everyone". Multi-instance configuration is a very niche setup
(particular, rarely used, option), and the only prob is that (a part)
of the thing isn't running after upgrade, - it's rather trivial to
start it.
It's a matter of my priorities anyway, - I assign them weight so if
I have spare time, I know where to apply it best. For this very issue
I don't have a solution anyway, so I'll probably ask for help here,
and unless someone steps in with a good solution, it will stay this
way for a while.
I just thought - I switched from restart to stop+start because if
some email comes during upgrade before restart, and old running
instance will try to execute new binary and fail, which will cause
it to throttle this particular service for 60s (by default). Which
isn't that bad. So that might be a solution here.
/mjt
