On 16 Oct 2018, at 14:56, Kamil Jońca via Exim-users <exim-users@???> wrote:
> I do not know if it is clear: this is not my words, neither I agreed
> with them (please note, that I opened this issue on github.)
...and you have a workaround in systemd via the KillMode switch, or the various timeout options. Or you could use Exim in queue-only mode with a frequent (say 30s) queue runner so it doesn't attempt immediate delivery when the local message is generated.
> I agreed that systemd should allow exim to work on current rules. But I
> don know how can I argue to Lennart Poettering to change his mind.
You can't :)
What you've shown us is (in my opinion) an incredibly niche case which has a variety of options available already to fix it. I have *never* heard of a systemd unit being used to send an email itself - I'm not saying it doesn't happen, but it seems a rather esoteric thing to do (to me). Of course, several hundred people will now tell me that they do it too!
I dare say you could probably do something with the runtime configuration too, or with the configuration of the 'mail' command - which you set in /etc/mail.rc, ~/.mailrc or similar:
set sendmail=/usr/sbin/exim -odq
That works for me - message injected but no immediate delivery and no forking of a child subprocess. Message delivered by next queue run.
If you set it in /etc/mail.rc, that works for all users.
Do those help?
Graeme
