alert: ... pread() read only

Maxim Dounin mdounin at
Tue Nov 19 09:21:12 UTC 2013


On Tue, Nov 19, 2013 at 09:39:44AM +0200, Nikolaos Milas wrote:


> The problem is that there is a repeating error of the form (I have
> changed real host name and web root path, as well as client IP
> address):
> 2013/11/17 12:39:14 [alert] 20709#0: *9059 pread() read only 38605
> of 39107 from "/path/to/web/root/HTML/gmap/gmapv3_auto_el.html"
> while sending response to client, client:,
> server:, request: "GET
> /HTML/gmap/gmapv3_auto_el.html HTTP/1.1", host: ""
> I found here:
> ...that this is probably related to the "open_file_cache" directive,
> and in fact I do use (based on advice found on the Internet):

It's not "related" to the "open_file_cache" directive, but the 
"open_file_cache" directive makes the underlying problem more 

The root cause of the messages in question is non-atomic file 
update.  Somebody on your system edited the file in question 
in-place, instead of re-creating it with a temporary name and then 
using "mv" to atomically update the file.

Non-atomic updates create a race: a file which is opened by nginx 
(and stat()'ed for nginx to know it's length) suddenly changes.  
This can happen in the middle of a response, and results in a 
corrupted response - first part of a response is from original 
file, and second is from updated one.  If nginx is able to detect 
the problem due to file size mismatch - it logs the message in 

The only correct solution is to update files atomically, i.e., 
create a new file and then rename to a desired name.

However, the "open_file_cache" directive makes the race window 
bigger by keeping files open for a long time.  Switching it off is 
a good idea if you can't eliminate non-atomic updates for some 


> Should I disable open_file_cache or not? (I do not entirely
> understand its implications.)
> How should we determine the directive benefits?
> Note: The aim is to be able to serve a few thousand requests per sec
> at peak, while normal traffic is < 20 reqs/sec.

I don't think that open_file_cache results in a measurable 
difference in your case.  I would recommend disabling it unless 
you have good reasons to enable it, just to simplify maintenance.

Maxim Dounin

More information about the nginx mailing list