httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34708] - Apache 2.0 seems not to work properly on NFS shared resources
Date Mon, 30 May 2005 11:57:45 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34708>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34708





------- Additional Comments From trawick@apache.org  2005-05-30 13:57 -------
file was originally 110 bytes but it has been truncated after the time that we
retrieved the size...  so we keep trying to 110 bytes over and over, allocating
memory each time

open("/usr/develop/CorriereOnline/baseroot/webroot/aa.html", O_RDONLY) = 8
gettimeofday({1117417939, 561092}, NULL) = 0
lseek(8, 0, SEEK_SET)                   = 0
read(8, "", 110)                        = 0
lseek(8, 0, SEEK_SET)                   = 0
read(8, "", 110)                        = 0
... lseek and read repeated forever

file-bucket-read needs to realize what has happened (hit EOF on file where we
expected to read more bytes), and keep from adding another bucket in this case...

current:

    /* If we have more to read from the file, then create another bucket */
    if (filelength > 0) {

maybe?

    if (filelength > 0 && *len != 0) {

core_output_filter is going to have to recognize this condition and decide what
to do; 

if data has already been sent (presumably including HTTP response header which
indicates how many bytes are to be sent), the best possibility may be to log an
error and drop the connection abruptly; 

FWIW, Apache 1.3 will usually SIGBUS when this happens (file truncated after
Apache find the file size), though that can be mitigated by sending truncatable
files through mod_include since 1.3 mod_include uses the simplest file I/O
model.    On a normal filesystem, as long as files are moved into the document
root without truncating in place, everything works fine.   When files in
document root are truncated, Apache can't send a meaningful response to the
client (irrespective of whether it dies with SIGBUS or loops).

So yes Apache needs to handle this situation more gracefully, but there are
limits to that gracefulness which are only resolved by avoiding the trucate
method of replacing file contents.

Some methods that truncate:
shell redirection
fopen() without append flag

A method that doesn't truncate:
use mv command to update file in documentroot from complete new file

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message