Package: postfix Version: 3.9.0-4 Severity: important There's a rather big question about the way how postfix starts in debian and how it's integrated with systemd. Filing this as a bug report, so the discussion wont get lost.
There's a number of issuse with multi-instance postfix startup as done in debian currently, and number of questions too. First of all, upstream postfix is pretty capable of managing its own instances, in a more general and easier way (in my opinion anyway) than it's currently done in debian. There's a single 'postfix' "service" which starts the whole thing, just like in debian (so there's no actual need to iterate instances like debian does in init.d/postfix script). There's `postmulti` upstream helper service which is more flexible than debian-offered setup, - it can manage related instances in a group, it understands that an instance can be disabled (which is even the default when creating a new instance), etc. But it does not interact well with systemd services concept, - hence we've a cripped-down setup in debian postfix package. 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. 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). On the contrary, when you do have actual postmulti setup, it can be made to work the way similar to how it is done by debian now. But please have in mind this is needed for a relatively small number of setups. 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. 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. At the same time, we can provide `postmulti.service` to manage individual instances the way it's done in debian now. This postmulti.service will be a "dummy" top-level service exactly the way `postfix.service` currently is, with postfix@.service being part of postmulti.service instead of postfix.service, and each postfix@.service (and postmulti.service) conflicting with regular/simple postfix.service. So the user enables either a simple postfix.service, or a more complicated postmulti.service, but not both. When postmulti.service is enabled (instead of postfix.service), individual instances are still managed the same way as before (using postfix@foo.service). But in order to start/stop whole thing, the user has to use postmulti.service instead of postfix.service. This is an inconvenience for sure, but I can't see how to do it the other way, for now. Maybe we can ship two versions for postfix.service, which points to either postfix-simple.service or postfix-multi.service (like default.target it done in systemd) - this way we'll be able to preserve the current naming entirely. By default, only the simple postfix.service will be enabled. While on upgrades, we can check if multiple instances are enabled, and if yes, enable the multi-instance service instead of the simple one. I'm not sure if we should care about possible local user-provided systemd overrides for postfix@-.service, - it's probably a good idea to migrate them to the same settings for postfix.service (or postfix-simple.service). For the init.d script, I think the best would be to just remove all multi-instance setup entirely and just run `postfix start|stop` which will take care of multi-instance postfix internally. What do you think? Thanks, /mjt
