www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Maloy <Bill.Ma...@long-beach.ms.us>
Subject os-linux/1592: Misleading mmap messages in error_log
Date Mon, 22 Dec 1997 17:15:29 GMT

>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:     Bill.Maloy@long-beach.ms.us
>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 <apbugs@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]




Mime
View raw message