In most cases, developers assume that when apr_file_write() returns APR_SUCCESS, everything went well, and move on. In reality, apr_file_write() returns APR_SUCCESS if *some* bytes got written successfully. One of the many cases when this could happen is when the server receive a signal in the middle of the write() system call. The kernel will not return -EINTR, but the number of bytes that have been written so far. The caller needs to check that all the bytes to write have been successfully written. This is more or less implemented by apr_file_write_full(). I wrote a fix for mod_log_config because log file corruption is sad. Patch is here: https://github.com/nviennot/apache-httpd/commit/fcbc7ed94 Note: flush_log() returns void, albeit apr_file_write_full() may fail. This issue is present in different part of the code base. Following a list of highly suspicious calls: https://github.com/apache/httpd/blob/62db628c/modules/slotmem/mod_slotmem_shm.c#L169 https://github.com/apache/httpd/blob/62db628c/modules/mappers/mod_rewrite.c#L1404 https://github.com/apache/httpd/blob/62db628c/modules/mappers/mod_rewrite.c#L1414 https://github.com/apache/httpd/blob/62db628c/modules/generators/mod_cgid.c#L1158 https://github.com/apache/httpd/blob/62db628c/modules/generators/mod_cgi.c#L298 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L742 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L752 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L901 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L910 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L977 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L988 https://github.com/apache/httpd/blob/62db628c/modules/cache/mod_cache_disk.c#L1054
replaced apr_file_write{,v} with apr_file_write{,v}_full in r1331110 some error checking is still missing.
LGTM