You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/03/01 14:06:07 UTC

DO NOT REPLY [Bug 17537] - 2.0.44 (and earlier) fail to serve .jpg files on RedHat 7.3

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17537>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17537

2.0.44 (and earlier) fail to serve .jpg files on RedHat 7.3





------- Additional Comments From trawick@apache.org  2003-03-01 13:06 -------
level set: I withdraw my previous comment about large file support being enabled.
I suspect that is not the case, because the symptom of enabling large file
support on problematic Linux boxes is a build failure, not a run-time failure.

So: no idea on cause here, just glad that "EnableSendfile Off" did the trick

You might want to turn sendfile back on temporarily and get an strace of
successfully sending a gif file so we can try to see what might be different.

Also, the jpg failures aren't just with a certain jpg that is being rewritten
frequently are they?  I see stat say the file is 10669 bytes and not much
further we tell sendfile to send that many bytes...  Only if the jpg file has
changed during that timeframe would our parameters to sendfile be wrong.
The other parms to sendfile are obviously correct.

Also, what sort of filesystem does the failing jpg file live on?  Is that a
different filesystem than gif files that work?  Some filesystems don't work with
sendfile.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org