$Revision: 1.99 $ ($Date: 2010/12/10 10:13:45 $)
Please note that this document refers to a version of the product which has been deprecated, and declared "end of life", in favor of the more recent version of the server. Information obtained here is likely to be outdated and inaccurate.
The latest version of this FAQ is available on the HTTP Server Wiki, at <http://httpd.apache.org/docs/1.3/misc/FAQ.html>. This version is no longer maintained, and contains inaccurate and grossly outdated information.
System error 1067
has occurred. The process terminated
unexpectedly.
" What does this mean?admin: not a valid
FDN: ....
" is logged.default.ida
and
cmd.exe
?Your Group
directive (probably in conf/httpd.conf) needs
to name a group that actually exists in the
/etc/group file (or your system's equivalent).
This problem is also frequently seen when a negative number
is used in the Group
directive (e.g.,
"Group #-1
"). Using a group name -- not
group number -- found in your system's group database
should solve this problem in all cases.
This message almost always indicates that the client
disconnected before Apache reached the point of calling
setsockopt()
for the connection. It shouldn't
occur for more than about 1% of the requests your server
handles, and it's advisory only in any case.
This is a normal message and nothing about which to be alarmed. It simply means that the client canceled the connection before it had been completely set up - such as by the end-user pressing the "Stop" button. People's patience being what it is, sites with response-time problems or slow network links may experience this more than high capacity ones or those with large pipes to the network.
In Apache version 1.2, the error log message about
dumped core includes the directory where the dump file
should be located. However, many Unixes do not allow a
process that has called setuid()
to dump core
for security reasons; the typical Apache setup has the
server started as root to bind to port 80, after which it
changes UIDs to a non-privileged user to serve
requests.
Dealing with this is extremely operating system-specific, and may require rebuilding your system kernel. Consult your operating system documentation or vendor for more information about whether your system does this and how to bypass it. If there is a documented way of bypassing it, it is recommended that you bypass it only for the httpd server process if possible.
The canonical location for Apache's core-dump files is the ServerRoot directory. As of Apache version 1.3, the location can be set via the CoreDumpDirectory directive to a different directory. Make sure that this directory is writable by the user the server runs as (as opposed to the user the server is started as).
Your kernel has been built without SysV IPC support. You
will have to rebuild the kernel with that support enabled
(it's under the "General Setup" submenu). Documentation for
kernel building is beyond the scope of this FAQ; you should
consult the
Kernel HOWTO, or the documentation provided with your
distribution, or a
Linux newsgroup/mailing list. As a last-resort
workaround, you can comment out the
#define USE_SHMGET_SCOREBOARD
definition
in the LINUX section of
src/conf.h and rebuild the server (prior to
1.3b4, simply removing
#define HAVE_SHMGET
would have sufficed).
This will produce a server which is slower and less
reliable.
These are symptoms of a fine locking problem, which usually means that the server is trying to use a synchronization file on an NFS filesystem.
Because of its parallel-operation model, the Apache Web server needs to provide some form of synchronization when accessing certain resources. One of these synchronization methods involves taking out locks on a file, which means that the filesystem whereon the lockfile resides must support locking. In many cases this means it can't be kept on an NFS-mounted filesystem.
To cause the Web server to work around the NFS locking limitations, include a line such as the following in your server configuration files:
LockFile /var/run/apache-lock
The directory should not be generally writable (e.g., don't use /var/tmp). See the LockFile documentation for more information.
This is a known problem with certain versions of the AIX C compiler. IBM are working on a solution, and the issue is being tracked by problem report #2312.
RedHat Linux versions 4.x (and possibly earlier) RPMs contain various nasty scripts which do not stop or restart Apache properly. These can affect you even if you're not running the RedHat supplied RPMs.
If you're using the default install then you're probably running Apache 1.1.3, which is outdated. From RedHat's ftp site you can pick up a more recent RPM for Apache 1.2.x. This will solve one of the problems.
If you're using a custom built Apache rather than the
RedHat RPMs then you should rpm -e apache
. In
particular you want the mildly broken
/etc/logrotate.d/apache
script to be removed,
and you want the broken /etc/rc.d/init.d/httpd
(or httpd.init
) script to be removed. The
latter is actually fixed by the apache-1.2.5 RPMs but if
you're building your own Apache then you probably don't
want the RedHat files.
We can't stress enough how important it is for folks, especially vendors to follow the stopping Apache directions given in our documentation. In RedHat's defense, the broken scripts were necessary with Apache 1.1.x because the Linux support in 1.1.x was very poor, and there were various race conditions on all platforms. None of this should be necessary with Apache 1.2 and later.
You should read the previous note
about problems with RedHat installations. It is entirely
likely that your installation has start/stop/restart
scripts which were built for an earlier version of Apache.
Versions earlier than 1.2.0 had various race conditions
that made it necessary to use kill -9
at times
to take out all the httpd servers. But that should not be
necessary any longer. You should follow the directions on how to stop and
restart Apache.
As of Apache 1.3 there is a script
src/support/apachectl
which, after a bit of
customization, is suitable for starting, stopping, and
restarting your server.
It means what it says; the Apache software can't determine the hostname of your system. Edit your conf\httpd.conf file, look for the string "ServerName", and make sure there's an uncommented directive such as
ServerName localhost
or
ServerName www.foo.com
in the file. Correct it if there one there with wrong information, or add one if you don't already have one.
Also, make sure that your Windows system has DNS enabled. See the TCP/IP setup component of the Networking or Internet Options control panel.
After verifying that DNS is enabled and that you have a valid hostname in your ServerName directive, try to start the server again.
Short answer: You need to install Winsock 2, available from http://www.microsoft.com/windows95/downloads/
Detailed answer: Prior to version 1.3.9, Apache for Windows used Winsock 1.1. Beginning with version 1.3.9, Apache began using Winsock 2 features (specifically, WSADuplicateSocket()). WS2_32.DLL implements the Winsock 2 API. Winsock 2 ships with Windows NT 4.0 and Windows 98. Some of the earlier releases of Windows 95 did not include Winsock 2.
We have seen this problem when Apache is run on systems along with Virtual Private Networking clients like Aventail Connect. Aventail Connect is a Layered Service Provider (LSP) that inserts itself, as a "shim," between the Winsock 2 API and Window's native Winsock 2 implementation. The Aventail Connect shim does not implement WSADuplicateSocket, which is the cause of the failure.
The shim is not unloaded when Aventail Connect is shut
down. Once observed, the problem persists until the shim is
either explicitly unloaded or the machine is rebooted.
Another potential solution (not tested) is to add
apache.exe
to the Aventail "Connect Exclusion
List".
Apache is affected in a similar way by any firewall program that isn't correctly configured. Assure you exclude your Apache server ports (usually port 80) from the list of ports to block. Refer to your firewall program's documentation for the how-to.
System error
1067 has occurred. The process terminated
unexpectedly
." What does this mean?
This message means that the Web server was unable to start correctly for one reason or another. To find out why, execute the following commands in a DOS window:
c: cd "\Program Files\Apache Group\Apache" apache
(If you don't get the prompt back, hit Control-C to cause Apache to exit.)
The error you see will probably be one of those preceding this question in the FAQ.
As of Apache 1.3.14, first check the Windows NT Event Log for Application errors using the Windows NT/2000 Event Viewer program. Any errors that occur prior to opening the Apache error log will be stored here, if Apache is run as a Service on NT or 2000. As with any error, also check your Apache error log.
admin: not a valid
FDN: ....
" is logged.
In the SuSE distribution, additional 3rd party authentication
modules have been added and activated by default. These modules
interfere with the Apache standard modules and cause Basic
authentication to fail. Our recommendation is to comment all
those modules in /etc/httpd/suse_addmodule.conf
and /etc/httpd/suse_loadmodule.conf
which are not
actually required for running your server.
default.ida
and
cmd.exe
?
The host requesting pages from your website and creating those entries is a Windows machine running IIS that has been infected by an Internet worm such as Nimda or Code Red. You can safely ignore these error messages as they do not affect Apache. ApacheWeek has an article with more information.
Problem: You are noticing restart messages in your error log, periodically, when you know you did not restart the server yourself:
[Thu Jun 6 04:02:01 2002] [notice] SIGHUP received. Attempting to restart [Thu Jun 6 04:02:02 2002] [notice] Apache configured -- resuming normal operations
Check your cron jobs to see when/if your server logs are being rotated. Compare the time of rotation to the error message time. If they are the same, you can somewhat safely assume that the restart is due to your server logs being rotated.
Module Magic Number (MMN) is a constant defined in Apache source that is associated with binary compatibility of modules. It is changed when internal Apache structures, function calls and other significant parts of API change in such a way that binary compatibility cannot be guaranteed any more. On MMN change, all third party modules have to be at least recompiled, sometimes even slightly changed in order to work with the new version of Apache.
If you're getting the above error messages, contact the vendor of the module for the new binary, or compile it if you have access to the source code.