On Sat, 17 May 2025 at 17:14, Helge Kreutzmann <deb...@helgefjell.de> wrote: > Am Sat, May 17, 2025 at 05:44:03PM +0200 schrieb Marc Haber: > > On Sat, May 17, 2025 at 01:44:57PM +0000, Helge Kreutzmann wrote: > > > In /etc/exim4 three files mention procmail: > > > > > > exim4-config: /etc/exim4/conf.d/transport/30_exim4-config_procmail_pipe > > > exim4-config: /etc/exim4/conf.d/router/700_exim4-config_procmail > > > exim4-config: /etc/exim4/exim4.conf.template > > > > > > But I never edited them directly, only via Debconf (probably when I > > > installed the machine. > > > > If you don't use procmail, you should deinstall it. Exim can deliver by > > itself. > > I use procmail on several machines, but right, on this one it is not > (much) used. I just wonder - is procmail incompatible with the updated > logcheck?
(it seems like this is the case, but it its not clear.) To be clear: All logcheck is doing is sending an email, it doesnt make any other assumptions on the mta so .... this should work. 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. but i dont use procmail so it may well be the difference. I suspect we might need to revert the system timer for trixie because there is clearly something more compleregualrlyx going on. > > 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. > > 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? > > That was a pretty stiff amount of work. recognise this! > > > > 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. whereas exim has slightly odd model where it starts a new process in the background (using suid i guess) to immediately deliver the email - systemd thinks this new process is part of the sending unit rather than exim's unit 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. > > My second guess is that for some reason Helge's system indeed runs > > logcheck's classical cron job AND the new systemd timer, and the systemd > > timer version shows the issue in question. I'd go ahead and debug why > > logcheck's classical cron job doesn't get disabled on Helge's system. 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 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.) > 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 > 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 > Should I revert this and look how it behaves? you could try - i predict you will get then get 3 emails: one from cron, and the same 2 from the timer
