Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #2 from Jeremy Harris <jgh146exb@wizmail.org> ---
As you saw, there is code to remove the directory. Does the effect occur for
a debug run? The only thing that comes to mind is the directory (and possibly
file/s) removal being tried but failing due to permissions.

I'm going to add logging for those calls failing, in any case.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #3 from Piotr Staszeski <tech@axit.pl> ---
The above output is from a debug run.

I had the same idea and modified spool_mbox.c, inserting the following:

/* remove directory */
if(rmdir(CS mbox_path) < 0) {
perror("Cannot delete");
}

which in the debug run produces

1208 end of ACL "acl_check_data": ACCEPT
1208 unspool_mbox(): unlinking
'/opt/smtp_data/data/spool/scan/1mpeHc-0000JU-3d/1mpeHc-0000JU-3d.eml'
Cannot delete: Directory not empty
1208 Writing spool header file:
/opt/smtp_data/data/spool//input/c/hdr.1mpeHc-0000JU-3d

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #4 from Piotr Staszeski <tech@axit.pl> ---
So this looks like the underlying NFS being too slow. On the other hand, with
the exactly same filesystem, and exim 4.94.2, everything has run smoothly.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #5 from Jeremy Harris <jgh146exb@wizmail.org> ---
Not sure how you conclude "too slow"?

Suggest a check on the return from the unlink a few lines above (and show
errno on fail).

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #6 from Piotr Staszeski <tech@axit.pl> ---
I concluded the unlink is successful based on the evidence the *eml files are
not there anymore. I am pretty sure however I have seen files starting with
.nfs for a while there. I think it would be better idea to list the contents of
mbox_path prior to deletion of the directory to be sure. I am going to pursue
tomorrow - if it happens the *eml is still there, then I am going to check the
unlink indeed.
Thanks for now, gonna write tomorrow.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

--- Comment #7 from Piotr Staszeski <tech@axit.pl> ---
We have tested the 4.95 version with the OS consisting of packages from our
previous update, which revealed that this is most probably not an Exim issue,
as the directory is successfully deleted there.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2834

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WORKSFORME

--- Comment #8 from Jeremy Harris <jgh146exb@wizmail.org> ---
Thanks - closing on that basis

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##