My original message didn't make it through moderation yet, but I ended
up finding the solution on this list by accident.
tip: use -odf when calling exim from a systemd oneshot service
https://lists.exim.org/lurker/message/20220614.201406.278f227f.en.html
Sorry for the inconvenience. Since I did not expect systemd to be the
culprit here, this thread didn't come up when I looked into the problem.
I came across it now by just browsing the list.
What ends up happening is that systemd terminates an exim4 process. This
amazingly also solves a different issue I was looking at completely
unrelated to Exim. To at least provide some value here, the argument
required for s-nail is -S mta-arguments="-odf".
Thanks to **Ian Kelling for the hint.
On 06.07.22 16:49, Kim-Alexander Brodowski wrote:
Hello fellow postmasters,
I'm experiencing a weird issue I hope somebody here can help me make
sense of.
Background:
We're using a small bash script, see below, to inform us when certain
systemd units fail. This is essentially because stuff runs in the
background and not everyone interested in the results of these tasks
can work with a terminal.
#!/bin/bash
if [ "$#" -ne 2 ]
then
echo "Usage: $(basename "$0") RECIPIENT UNIT" 1>&2
exit 1
fi
. /usr/lib/iserv/cfg
echo "Sending status report of $2 to $1 ..."
HOSTNAME="$(hostname)"
HOSTNAME="${HOSTNAME:-localhost}"
MAIL_DOMAIN="${Domain:-$HOSTNAME}"
MAIL="root@${MAIL_DOMAIN}"
s-nail --batch-mode -s "$2" -r "$MAIL" -C "X-IServ-systemd-Unit:
$2" -. "$1" <<ERRMAIL
$(systemctl status -n 0 --full "$2")
$(journalctl -u "$2" --since "$(systemctl show "$2" --property
ExecMainStartTimestamp --value)")
This message was automatically generated by $0 on $HOSTNAME.
ERRMAIL
#sleep 10
If anyone is interested in the corresponding unit file and config for
other units, I can provide those as well, but I don't think they
provide additional context here.
When this script is called interactively, emails generated are pretty
much instantly delivered to Cyrus, our MDA. When the script is called
by systemd, the mail instead is queued for some time by exim4 and
eventually delivered. This is where our problem lies: We prefer
instantaneous delivery in this instance.
s-nail sends its mail using sendmail, which on our platform of choice,
Debian Bullseye, is part of the exim4-daemon-heavy package.
I've traced s-nails call to sendmail and there is no difference in
arguments when being called interactively. The problem appears to be
somewhere on Exim's side.
I've enabled debug logging, but looking at the output, I don't see
anything of particular interest. I've attached an excerpt.
Now to the oddity justifying the odd subject: In the script above,
there is a sleep statement commented out. This shouldn't really do
anything, except for increasing the runtime of the bash script.
However, uncommenting that actually makes email delivery instantaneous
again. Yeah ... It almost seems like exim4 somehow speeds things up if
the calling process sticks around for some time. Maybe it feels it's
being ... pressured?
Joking aside, I've looked at stuff like queue_only_load, but I don't
think these options are to blame here.
Maybe somebody has an idea of what is going wrong here. Thanks in
advance. We love Exim ;)
--
Kind regards,
Kim Brodowski
Telefon: +49 531 38821-01
Fax: +49 531-38821-999
E-Mail: i...@iserv.eu
Internet: https://iserv.de
Zentrale: IServ GmbH, Bültenweg 73, 38106 Braunschweig
Niederlassungen:
IServ GmbH, Girardetstr. 6, 45131 Essen
IServ GmbH, Fanningerstraße 13, 10365 Berlin
USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.de/privacy
IServ - aus der Schule für die Schule
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
