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
    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
    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
    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
    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
    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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.