I can verify that apache2-mpm-worker is indeed having this problem when serving static files from a CIFS mount on a modern lenny system.
Each HTTP fetch is capable of pulling some smallish amount of bytes
(~10K for some connections i've tried) before the TCP connection
abruptly terminates.
On such a pull, an strace shows:
> sendfile(9, 11, [0], 85678) = -1 EOVERFLOW (Value too large for defined data
> type)
at the time of the send, and if LogLevel is set to debug, apache only
logs the following single line to error.log (client IP has been
anonymized):
> [Wed Mar 25 02:30:01 2009] [info] [client www.xxx.yyy.zzz] (75)Value too
> large for defined data type: core_output_filter: writing data to the network
I agree with Bastian Blank that it seems like Apache is misbehaving
here. If sendfile(2) fails, shouldn't apache gracefully fall back to
non-sendfile behavior (based on the number of bytes transferred, which
should be in the *offset parameter).
sendfile(2) even says:
Applications may wish to fall back to read(2)/write(2) in
the case where sendfile() fails with EINVAL or ENOSYS.
Interestingly, when i tried experimenting with this by doing sendfile
from a CIFS-mounted file through a local UNIX-domain socket [0],
sendfile(2) returned EOVERFLOW, but the entire file transferred cleanly,
even for a ~5MB file.
Regards,
--dkg
[0] http://cmrg.fifthhorseman.net/browser/trunk/test/sendfile
signature.asc
Description: OpenPGP digital signature
