On Sat, 17 May 2025, 11:18 Helge Kreutzmann, <deb...@helgefjell.de> wrote:
> Hello Richard, > Am Sat, May 17, 2025 at 11:12:05AM +0100 schrieb Richard Lewis: > > On Sat, 17 May 2025, 09:30 Helge Kreutzmann, <deb...@helgefjell.de> > wrote: > > > Am Fri, May 16, 2025 at 06:35:14PM +0000 schrieb Helge Kreutzmann: > > > > Am Fri, May 16, 2025 at 06:58:44PM +0100 schrieb Richard Lewis: > > > > > > > > > https://salsa.debian.org/debian/logcheck/-/blob/debian/sid/src/logcheck?ref_type=heads#L328 > > > > > > > > > > add a new line with a " sleep 30 " before the return (and after the > > > call to > > > > > mime-construct (30 seconds is way too long - probably 10s is > enough!) > > > > > > > > Ok, I added it. So I can report tomorrow what (if) changed. > > > > > > I can see only a slight change. The exim error is the same, and two > mails > > > arrive, one shortly after the hour, but the 2nd one always 24 minutes > later > > > (before this, the 2nd mail arrived at a non deterministic time). > > > > > > Does this help you? > > > > > > > hmm... not what i was expecting! > > > > what happens if you run mailq between the 2 emails arriving - is there > > perhaps something frozen? > > For the next one: > > root@twentytwo:~# mailq > 13m 3.0K 1uGEMm-00000000KGp-1rQA <logch...@twentytwo.helgefjell.de> > logch...@twentytwo.helgefjell.de aha, so this is what i thought --exim is getting the email, delivering it immediately but -- for some reason -- also keeping a copy in the queue. the 2nd email is happening when exim does its regular queue processing. this usually happens when systemd prevented exim from writing to whatever database it uses. although 1. i have never seen 2 copies like this and 2. there's no systemd hardening in the debian unit. could systemd have changed something? > > > what is in the exim mainlog for the 2nd email? > > For the previous run: > 2025-05-17 11:10:01 1uGDYP-00000000It2-0waZ <= > kreutzmannhe...@helgefjell.de H=(twentytwo.helgefjell.de) [::1] P=esmtp > S=6850 id=courier.00000000682850e3.000d3...@mail.helgefjell.de > 2025-05-17 11:10:02 1uGDYP-00000000It2-0waZ => helge <helge@localhost> > R=procmail T=procmail_pipe > hmm. this doesnt look like a default exim configuration to me? -- what is the role of procmail on this system? ( it should be a local route and transport here, but is doing esmtp??) why are there several variations of the hostname/mailname? you've got the system appearing as twentytwo.helgefjell.de but also helgefjell.de and mail. helgefjell.de <kreutzmannhe...@helgefjell.de> (and later just localhost) and it seems to be delivering the mail over smtp rather than local delivery --- even if you run your own email service it shouldnt be doing that! is there a mismatch between the names in /etc/mailname the name in /etc/hosts the hostname and the dns records for those domains? (i dont know why that would cause this, if other mails to the logcheck user work) 2025-05-17 11:10:02 1uGDYP-00000000It2-0waZ Completed > so there is one mail from kreutzmannhe...@helgefjell.de to helge@localhost 2025-05-17 11:10:02 1uGDYP-00000000It2-1FK6 <= kreutzmannhe...@helgefjell.de > H=(twentytwo.helgefjell.de) [::1] P=esmtp S=7008 id= > courier.00000000682850e3.000d3...@mail.helgefjell.de > 2025-05-17 11:10:03 1uGDYP-00000000It2-1FK6 => helge <helge@localhost> and a 2nd one R=procmail T=procmail_pipe > 2025-05-17 11:10:03 1uGDYP-00000000It2-1FK6 Completed > message was queued for sending but it does not realise it was delivered - messae is in a queue. (i have seen this happen when 2025-05-17 11:26:45 Start queue run: pid=73727 > 2025-05-17 11:26:45 1uGDQi-00000000Ign-2mF0 => helge < > logch...@twentytwo.helgefjell.de> message released from the queue. but now for logcheck user at a different host. it's like exim thinks it is 2 different hosts? is there some procmail rewriting going wrong here (new theory: local issue triggered by a change in how logcheck sets the "from"/"sender" address)? R=procmail T=procmail_pipe > 2025-05-17 11:26:45 1uGDQi-00000000Ign-2mF0 Completed > 2025-05-17 11:26:45 End queue run: pid=73727 > > (The entrys at 11:02 o'clock are when the mails get initiated, as you can > see, at 11:26 o'clock the 2nd one was deliverd. > > > > Should I now undo this change and go for the 2nd change? > > > > > > > i think that would at least confirm if this is systemd+exim-related in > the > > way i suspect > > So I will undo the manual change for the logcheck script after the > delivery > of the 2nd mail? > worth a try (although it shouldnt matter to leave the sleep in place)