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
Attachment:
signature.asc
Description: OpenPGP digital signature