Hmm, Linux raises SIGBUS if an mmap is used after the underlying file
has been truncated (see [1]).
See also https://bz.apache.org/bugzilla/show_bug.cgi?id=46688 .
Niklas, just to clarify: you're not willfully truncating large files as
they're being served, right? I *can* reproduce a SIGBUS if I start
truncating files during my stress testing. But EnableMMAP's documentation
calls that case out explicitly.
We're using our own large-file tuned cache module (I know, we should really
publish it properly), and clean on oldest atime with a script that does rm.
There's nothing cache-related that I know of that ever truncates files.
Bah. This particular server seems to have sporadic IO errors on the
cache filesystem. I'm guessing that this could show up as a truncated
file in the mmap sense of things, with SIGBUS and all. I should have
caught on when I only saw the issue on one host :-/
Methinks this makes mmap+ssl a VERY bad combination if the thing
SIGBUS:es due to a simple IO error, I'll proceed with disabling mmap
and see if that is a viable way to go for our workload...
We do sendfile for vanilla http, I'm guessing that's why we've never
hit this before.
So, sorry for the noise. You learn something new every day...
Just to rule it out, I changed our httpd init script to leave the stacksize
ulimit at Linux default (8MB) without changing anything else.
I'll probably leave this in though, as I'm guessing this usecase is
what gets the bulk of testing...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [email protected]
---------------------------------------------------------------------------
This tagline SHAREWARE. Send $5.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
