Re why the service says "active (exited)", I can the immediate reason why that is the case. It's because if you look a little closely, the 'ExecStart' command of postfix.service is /bin/true (which is a tiny commandline program which simply returns the boolean value of True - or in the case of bash, exit code 0 aka "success"). So the all the service does is runs a command that always returns "success", then exits.
But I'm guessing that doesn't really answer your question. I'm guessing your real question is why it's like that at all... TBH, I have no idea...!
Although I think the clue is that there is also a postfix@-.service. When a service name has an '@' in the name, it means that it's an instance of a service generated from a template. My guess is that Postfix has a single generic service (postfix.service) which doesn't actually do anything, other than act as a "master service" for at least one (but likely more, depending on load and/or some other condition(s)) individual instance service (i.e. postfix@-.service) that actually do the work. Those individual instances are likely triggered by something else. Perhaps the volume in the mail queue?
TBH, I'm only guessing and I have no idea why they've gone that route. But it all seems to be running as it should, so that's all good.
If you are particular interested in trying to understand why Postfix is setup the way that it is, I suggest some you do some reading. I suggest starting with the Debian Postfix changelog, then probably broadening to searching on the Debian bugtracker and mailing lists (TurnKey is based on Debian; v15.x = Debian 9/Stretch). The answer to why it's the way it is is was almost certainly discussed and decided 3 or 4 (+/-) years ago by people way smarter than me! :)
Glad to hear that you got it going! :)
Awesome news that you got it going! :)
Re why the service says "active (exited)", I can the immediate reason why that is the case. It's because if you look a little closely, the 'ExecStart' command of postfix.service is /bin/true (which is a tiny commandline program which simply returns the boolean value of True - or in the case of bash, exit code 0 aka "success"). So the all the service does is runs a command that always returns "success", then exits.
But I'm guessing that doesn't really answer your question. I'm guessing your real question is why it's like that at all... TBH, I have no idea...!
Although I think the clue is that there is also a postfix@-.service. When a service name has an '@' in the name, it means that it's an instance of a service generated from a template. My guess is that Postfix has a single generic service (postfix.service) which doesn't actually do anything, other than act as a "master service" for at least one (but likely more, depending on load and/or some other condition(s)) individual instance service (i.e. postfix@-.service) that actually do the work. Those individual instances are likely triggered by something else. Perhaps the volume in the mail queue?
TBH, I'm only guessing and I have no idea why they've gone that route. But it all seems to be running as it should, so that's all good.
If you are particular interested in trying to understand why Postfix is setup the way that it is, I suggest some you do some reading. I suggest starting with the Debian Postfix changelog, then probably broadening to searching on the Debian bugtracker and mailing lists (TurnKey is based on Debian; v15.x = Debian 9/Stretch). The answer to why it's the way it is is was almost certainly discussed and decided 3 or 4 (+/-) years ago by people way smarter than me! :)