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-Alexander Brodowski
IServ GmbH
Entwicklung
Bültenweg 73
38106 Braunschweig
Telefon: +49 531 22 43 666-0
Fax: +49 531 22 43 666-9
E-Mail: Kim.Brodowski@iserv.eu
Internet: https://iserv.eu
USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy
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-Alexander Brodowski
IServ GmbH
Entwicklung
Bültenweg 73
38106 Braunschweig
Telefon: +49 531 22 43 666-0
Fax: +49 531 22 43 666-9
E-Mail: Kim.Brodowski@iserv.eu
Internet: https://iserv.eu
USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822
Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig
Grundsätze zum Datenschutz: https://iserv.eu/privacy
Attached Files:
-
debuglog (3.70 KB)