Hello Michael, 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. However you might want to consider what I said here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849584#30 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. > 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. > 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. 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. > 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? Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
