My setup includes a script that send a mail to a local user via the exim command line. This script is called as root (Reality is of course more complicated, but this seems to be a minimal working example).

cat /home/jens/testmail | /usr/bin/exim -bm jens

Running this script from a root shell works fine. The mail is delivered without problems.

Now I try to automate this script and call it from a systemd service:

Description=Send mail to jens



Running systemctl start send_mail.service does not deliver the mail, but places it in the exim queue to be delivered later. In my real setup, I find lines reading

... exim[275968]: 2020-07-16 23:09:40 1jwB8O-0019n4-Lj failed to write to main log: length=91 result=-1 errno=9 (Bad file descriptor)
... exim[275968]: write failed on panic log: length=116 result=-1 errno=9 (Bad file descriptor)

in my journal. To my knowledge, I have no exim-specific environment variables for my root shell. What could be the cause of this different behavior?

I am using exim 4.94 on Arch Linux. Please ask if you need further details.

  • 1. Generally speaking, using sudo inside systemd is wrong or at least a "code-smell" as systemd subsumes sudo. In your case "- u" should become a "user=" section. See. 2. Likewise I expect systemd would be unhappy to peek inside /home. Move your file somewhere public like /etc /tmp and so on.
    – Rusi
    Commented Jul 18, 2020 at 10:41
  • Also since exim is being reached you could pass it option to be more verbose like -v or -d. (I know nothing of exim!)
    – Rusi
    Commented Jul 18, 2020 at 11:00
  • I am using sudo here because the 'send_mail' script actually does its thing for multiple users. I will try and see if I can solve this another way without sudo.
    – Jens
    Commented Jul 19, 2020 at 8:19
  • There are templates for this sort of thing See here for templates and the %U specifier but before that: Does it work without sudo?
    – Rusi
    Commented Jul 19, 2020 at 9:45
  • Actually, the sudo bits are a red herring. I removed them all and still get the same results. I'll update my question.
    – Jens
    Commented Jul 29, 2020 at 13:26

1 Answer 1


This issue seems to be caused by systemd killing the spawned exim process as soon as send_mail has finished executing.

It can be solved by either waiting an appropriate time at the end of send_mail, or setting the KillMode option in the systemd unit to process or none (which the manual recommends against).


  1. https://systemd-devel.freedesktop.narkive.com/nV1QMO8j/exim4-only-queues-mails-sent-by-systemd-service
  2. https://www.freedesktop.org/software/systemd/man/systemd.kill.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .