On Sat, May 17, 2025 at 06:58:56PM +0100, Richard Lewis wrote:
There is a known 'incompatibility' between systemd and exim that both
upstreams have explicitly declined to address - but it's
not clear (to me anyway) why you are hitting this -- ive been using
systemd and logcheck (and several other local email-sending units) for
over
a year with hardening and (after much pain) it now works for me - i
get an email every single day from a shell script in a systemd unit.
And all those scripts alos deliver via /usr/lib/sendmail?
Are you refering to the suid issue that I mentioned or is that
incompatibility something else?
but i dont use procmail so it may well be the difference.
I don't think so.
> I have had much fun with sending e-mail from a systemd unit as well, but
> that systemd unit is rather verbose and limited. I ended up using a helper
> program to deliver mail and not calling /usr/lib/sendmail any more. See:
>
>
https://salsa.debian.org/debian/aide/-/blob/debian/latest/debian/aide-common.dailyaidecheck.service
this is interesting - i found i needed to have slightly different
settings. but in debian's logcheck unit there is no settings for any
capabilities.
aide is using capabilities to allow reading everything without running
as root. logcheck's situation is different.
>
https://salsa.debian.org/debian/aide/-/blob/debian/latest/debian/bin/dailyaidecheck
i think this uses s-nail whereas logcheck uses mime-construct -- does
s-nail perhaps block until the mail is 'delivered'? or use smtp?
s-nail uses smtp, which helps going around the suid problem that my
hardened unit experienced. Exim uses a classical design where it needs
to elevate privileges to write to its queue when it is invoked by a
normal system user either directly or via the /usr/lib/sendmail alias.
> My first guess is that the suid bit does not work when /usr/lib/sendmail is
> invoked from the systemd unit, and running as logcheck exim can indeed not
> do anything.
my understanding is that systemd assumes that all processes started by
a unit are part of that unit. so it wants
the mail sender (logcheck.server) to start a program to send data to
exim (which is in its own cgroup), and block until that is done.
When logcheck pipes the mail through /usr/lib/sendmail, this does not
affect the running exim daemon at all. The exim process invoked via
/usr/lib/sendmail gets started with root privieges because it is suid
root (I suspect that systemd somehow prevents this, which is a good
thing for almost all programs EXCEPT exim or another traditional MTA),
writes the message to the queue AND tries sending the message right away
(if exim's load control mechanisms allow that). The exim daemon only
comes into play when the exim invoked via /usr/lib/sendmail is somehow
unable to deliver the message right away. In this case the message
remains in the queue and gets sent by the next queue run.
whereas exim has slightly odd model where it starts a new process in
the background (using suid i guess) to immediately deliver the email
That is how MTAs have always worked before qmail and postfix came
around.
- systemd thinks this new process is part of the sending unit rather
than exim's unit
systemd correctly think so. This new process does not have anything to
do with the exim daemon. Both processes run the same binary, but they
don't have anything to do with each other.
and so has a tendency to kill it, when the "main"
process exits or stop it working in various ways.
Each upstream considers the other one to be wrong.
I'd expect the call to /usr/lib/sendmail to not return until the exim
process has finished. But I might be wrong here. Would need to look at
an strace to make sure.
that was my first thought, but i am no longer sure - i think that it is also
possible that exim delivers the email but, before it can remove it
from the queue, systemd
tears down the logcheck unit, and so exim retries, and this makes a duplicate.
I have yet to see log evidence that exim actually delivers the message
twice.
(i see regularly see this when adding hardening to the a systemd unit
that sends mail- but ive nver seen 2 emails, i
have only seen an email left in the queue, or frozen. and debian's
unit has no hardening.)
If a message delivered to /usr/lib/sendmail by a non-root process ends
up in the queue this is evidence that privilege escalation using suid
has actually worked. The exim process invoked via /usr/lib/sendmail
would not be able to write to the queue otherwise, and it would not be
able to write to its log either. If exim cannot write to its log, it
tries to write to its panic log, and if that doesn't work it uses the
syslog(2) call to log to syslog, which usually works without root
privileges, and I suspect this is what we are seeing here.
If systemd would kill exim too early, exim would probably not get any
opportunity to log to syslog either.
Before the update I get mails with the subject:
Reboot: twentytwo.helgefjell.de 2025-05-16 15:54 +0200 System Events
After the reboot, now mails with this subject are sent; however, the
content is there (i.e. the filtered logs from the reboot are sent).
you mean "no mails with this subject are sent"? this is expected -
logcheck's cron does a (pointless) extra run after a reboot -- the
_only_ difference is that it adds the word
"reboot" in the subject. this isnt done under systemd
"send" is ambiguous on this level. When /usr/lib/sendmail returns to the
calling process, the calling process thinks it has "sent" the message.
That doesn't mean that the message was acutally "delivered" to its
destination. It might still be on the MTA's queue.
This terminology might seem nitpicking, it is still vital to understand
to be able to debug.
The cron.log says (before the update):
2025-04-14T00:02:01.739639+02:00 twentytwo CRON[11492]: (logcheck) CMD ( if [
-x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi)
and after the update:
2025-05-17T18:02:01.470178+02:00 twentytwo CRON[110761]: (logcheck) CMD ( if [ ! -d
/run/systemd/system ] && [ -x /usr/sbin/logcheck ]; then nice -n10
/usr/sbin/logcheck; fi)
So the cron commands changed during the update.
yes - the cron job is still running, but only if you are not booted
under systemd
The _cron job_ is still started, it just decides to not do anything.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
