On Mon, Sep 24, 2018 at 1:38 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > > On Mo, 24.09.18 20:34, Kamil Jońca (kjonca@xxxxx) wrote: > > > This didn't work well enough IIRC, but if it did, then it'd provide almost postfix-like architecture. > > > > > > Or just making 'sendmail' send a SIGALRM to the main daemon would do the job perfectly well, I suspect... > > > > But I still does not know, where is the problem, why exim doest not play > > well with systemd ... > > Here's an educated guess: your script terminates, so that that systemd > decides your service has ended. In such a case it kills any left-over > processes of the service, and this will include the exim process > forked off into the bg, because it is attributed to your script's > context. > > Thus the exim queue runner might be forked off, but it wil be > immediately terminated by systemd again... This is exactly what exim does when run via sendmail (which mail and mutt likely use behind the scenes). I had a very similar setup to the OP using exim on one of our servers and was perplexed why the queue wasn't being flushed immediately. Here's what I wrote our git history: I had naively thought that sendmail used SMTP to send a mail to the local MTA. That's actually not the case for either exim or postfix, which use internal procedures to queue and send the mail. Normally that's not a problem except when sendmail is run by a systemd service. Then the way that processes are spawned to queue and send the mail have to match the service type. In the case of exim, the sending process actually forks from sendmail, which systemd kills before it can run if the service type is set to oneshot. I ended up just writing python script to send the mail via SMTP to the localhost. -- Dan _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel