package: logcheck
version: 1.4.4
(following investigation of #1105792 , which i could not reproduce -
but maybe this is relevant)
This assumes exim, but i believe applies to postfix as well.
The systemd timer works "fine", but the mail is actually being
delayed. If you do
# tail -n0 -f /var/log/exim4/mainlog &
# logger bad && systemctl start logcheck
2025-05-18 22:31:06 1uGlb8-000000000iC-35Cw <= logcheck@mailname
U=logcheck P=local S=2858
you see there is only one line in exim's mainlog: the mail was passed
to exim OK, but was not immediately delivered. The mail is actually
stuck in a queue:
# mailq
2m 2.8K 1uGlb8-000000000iC-35Cw <logcheck@mailname>
logcheck@mailname
the delivery only happens once exim does its regular queue-running (or
you can do 'runq' to deliver immediately) - this happens every 30
minutes by default. You can probably also see the delay in the
'Received' headers.
Adding a sleep to the systemd service fixes this:
# systemctl edit logcheck.service
[Service]
ExecStart=sleep 10
and then you will see that the mail is also delivered right after logcheck runs.
(i found even a sleep 0.5 was enough, but maybe it depends on <something>):
# logger good && systemctl start logcheck
2025-05-18 22:42:13 1uGllt-000000000NK-33ae <= logcheck@mailname
U=logcheck P=local S=10245
2025-05-18 22:42:13 1uGllt-000000000NK-33ae => user
<logcheck@mailname> R=local_user T=mail_spool
2025-05-18 22:42:13 1uGllt-000000000NK-33ae Completed
no delay.
As i said in #1105792, i think this is to do with systemd and exim
taking a somewhat incompatible approach, -- see
https://systemd-devel.freedesktop.narkive.com/nV1QMO8j/exim4-only-queues-mails-sent-by-systemd-service
i thought this was an issue when adding hardening to the unit, but it
seems to happen anyway - it's easy to miss as the "From" header doesnt
show there was any delay.
A "workaround fix" could be to add a "ExecStart=sleep 10" to the
logcheck.service.
