Bug 64834 - Sporadic file truncation or excessive NULL bytes at the end
Summary: Sporadic file truncation or excessive NULL bytes at the end
Status: RESOLVED DUPLICATE of bug 54962
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.41
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2020-10-20 19:05 UTC by mmd.osm
Modified: 2020-10-22 08:37 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description mmd.osm 2020-10-20 19:05:39 UTC
OpenStreetMap publishes a replication status file under https://planet.openstreetmap.org/replication/minute/state.txt, which is served as static content and gets updated atomically on the filesystem every minute. File sizes might vary slightly from minute to minute, e.g. 158 bytes, 168 bytes.

Consumers reading from that file have reported sporadic issues, like truncated files, or files with excessive NULL bytes towards the end.

Our observations have shown that although the file gets updated atomically on the file system, Apache serves the _new_ state.txt file contents using the _old_ state.txt file length. This way, some response might lack the last 10 Bytes, or there's an additional 10 NULL bytes towards the end.

We're suspecting that there might be some race condition, where checking the file size and processing the actual file contents might see different versions of that file.

Is is a valid use case to change a minutely changing file as static content? Is this a bug or works-as-designed?

Downstream issue: https://github.com/openstreetmap/operations/issues/465
Comment 1 Ruediger Pluem 2020-10-21 07:38:34 UTC
Have you tried setting

EnableMMAP Off


for the directory that contains the file?

<Directory /directory>
    EnableMMAP Off


<Location /replication/minute>
    EnableMMAP Off
Comment 2 Joe Orton 2020-10-21 07:57:22 UTC
I think this is the race (e.g. bug 47693, I think there are more bugs on this) between the stat() which is used to determine content-length and then opening the file to send it.  It's a bug but it's designed in, fairly nasty really.  Padding the file to a constant length would work around it.  Or somehow ensuring the file is streamed as if it doesn't have a fixed C-L.  It would be a very simple replacement for the default_handler which doesn't have this bug, but not sure how to do it efficiently with the code as shipped.
Comment 3 Christophe JAILLET 2020-10-21 16:07:17 UTC
Also see bug 54962 which looks to be similar.
A patch is pending there.
Comment 4 Joe Orton 2020-10-22 08:37:15 UTC
Thanks, let's just track this in one place then.

*** This bug has been marked as a duplicate of bug 54962 ***