>Number: 1592 >Category: os-linux >Synopsis: Misleading mmap messages in error_log >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Mon Dec 22 09:20:00 PST 1997 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.3b3 >Environment: Linux longbeach 2.1.65 #2 Fri Nov 21 23:50:48 CST 1997 i586 unknown gcc version 2.7.2.3 >Description: Having recently installed 1.3b3, we are now seeing error messages of the form [Mon Dec 22 00:07:26 1997] [crit] (2)No such file or directory: mmap_handler: mm ap failed: /home/staz/stazsoftware/prodall.html for files that really *do* exist: $ ls -al /home/staz/stazsoftware/prodall.html -rw-rw-r-- 1 tech staz 3535 Dec 8 09:12 /home/staz/stazsoftware/prodall.html
Most client connections reference the "missing file" successfully: firestone.alexa.com - - [22/Dec/1997:00:07:47 -0600] "GET /prodall.html HTTP/1.1" 200 3535 But the "critical" stamp in the error log is getting our attention. If a mmap fails, is the server reverting to conventional "I/O"? Just how critical an error is this, really? >How-To-Repeat: I've not been able to force this error condition. >Fix: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
