https://bugs.exim.org/show_bug.cgi?id=3040
Jeremy Harris <jgh146exb@wizmail.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unallocated@exim.org |jgh146exb@wizmail.org
Priority|medium |low
Target Milestone|Exim 4.97 |Exim 4.98+
--- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
Worth fixing, even though it's a rather obscure situation.
At an initial look, we can make sure to respond 451 rather than 250.
We can try to remove the spoolfiles, though the filesystem state is somewhat
uncertain at that point. If that works, we won't get a duplicate.
Logging is harder. We log message-accept before closing the d-file, because
the close release the lock stopping any other process (eg. a queue-runner)
picking it up, and we want to know that the log operation succeeded
(it could die for a full FS, for example). I don't want to mess with the
long-present sequencing. So the best I can think of is to append more logging
to say the the message-accept was actually aborted.
I think the logging muddle is preferable to a double-deliver.
I've placed a commit (f70940c94) in the current 4.next which does that.
Seperately, we might consider doing an fdatasync() right after the last
fflush(),
in an attempt to flush out the specific error observed early enough to sort
out the log muddle. I don't know if this will have performance impact, but
it does feel right (just on data-security grounds).
Dealing with fclose() errors would still need to be done; this is not a
replacement.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Jeremy Harris <jgh146exb@wizmail.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unallocated@exim.org |jgh146exb@wizmail.org
Priority|medium |low
Target Milestone|Exim 4.97 |Exim 4.98+
--- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
Worth fixing, even though it's a rather obscure situation.
At an initial look, we can make sure to respond 451 rather than 250.
We can try to remove the spoolfiles, though the filesystem state is somewhat
uncertain at that point. If that works, we won't get a duplicate.
Logging is harder. We log message-accept before closing the d-file, because
the close release the lock stopping any other process (eg. a queue-runner)
picking it up, and we want to know that the log operation succeeded
(it could die for a full FS, for example). I don't want to mess with the
long-present sequencing. So the best I can think of is to append more logging
to say the the message-accept was actually aborted.
I think the logging muddle is preferable to a double-deliver.
I've placed a commit (f70940c94) in the current 4.next which does that.
Seperately, we might consider doing an fdatasync() right after the last
fflush(),
in an attempt to flush out the specific error observed early enough to sort
out the log muddle. I don't know if this will have performance impact, but
it does feel right (just on data-security grounds).
Dealing with fclose() errors would still need to be done; this is not a
replacement.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/