exim-users--- via Exim-users <exim-users@???> (Mo 22 Apr 2019 19:57:42 CEST):
…
> Exim 4.90.1-1ubuntu1 with sa-exim running on one hosts (Ubuntu standard
> config with TLS enabled, sa-exim adding some headers) acting as
> smarthost, second Exim generating mail (store some 10+ messages in queue
> and trigger delivery via e.g. "exim4 -qff") and using that smarthost. As
> soon as more than one message was delivered via one connection, files
> got corrupted (not in every delivery but with a chance of about 10-20%,
I had a similar issue with broken -H files. Though if I understood your
issue right, only the symptoms are similar, the root cause might be
different.
But in my case the root cause was clearly a bug. (My case: multiple Exim
instances on multiple hosts used the same (NFS shared) spool directory).
Maybe there is some relation (again: I'm quite convinced that it isn't
related, as the rest of the -H file handling looks ok to me. Especially
there is a fclose(hdr.<PID>) and rename(hdr.<PID>, <MESSAGE_ID>-H)), so the next
message should get a fresh hdr.<PID>, even if it has the same PID.
Can you apply commit cb80814d1 to your Exim? (It breaks the testsuite,
to fix this, there is another commit).
Basically it is the following change:
diff --git a/src/src/spool_out.c b/src/src/spool_out.c
index 3970206cb..a4a734a1a 100644
--- a/src/src/spool_out.c
+++ b/src/src/spool_out.c
@@ -134,8 +134,7 @@ struct stat statbuf;
uschar * tname;
uschar * fname;
-tname = spool_fname(US"input", message_subdir,
- string_sprintf("hdr.%d", (int)getpid()), US"");
+tname = spool_fname(US"input", message_subdir, US"hdr.", message_id);
if ((fd = spool_open_temp(tname)) < 0)
return spool_write_error(where, errmsg, US"open", NULL, NULL);
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
