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
Have you tried setting EnableMMAP Off http://httpd.apache.org/docs/2.4/mod/core.html#enablemmap for the directory that contains the file? <Directory /directory> EnableMMAP Off </Directory> or <Location /replication/minute> EnableMMAP Off </Location>
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.
Also see bug 54962 which looks to be similar. A patch is pending there.
Thanks, let's just track this in one place then. *** This bug has been marked as a duplicate of bug 54962 ***