$Revision: 1.7 $ ($Date: 2000/11/13 02:03:36 $)
The latest version of this FAQ is always available from the main Apache web site, at <http://www.apache.org/docs/misc/FAQ.html>.
If you are reading a text-only version of this FAQ, you may find numbers enclosed in brackets (such as "[12]"). These refer to the list of reference URLs to be found at the end of the document. These references do not appear, and are not needed, for the hypertext version.
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 experiences 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 localhostor
ServerName www.foo.comin 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. Instructions for temporarily removing the Aventail Connect V3.x shim can be found here: "How to Remove Aventail Connect v3.x from the LSP Order for Testing Purposes."
Another potential solution (not tested) is to add apache.exe
to the Aventail "Connect Exclusion List". See this link for details:
"How to Add an Application to Aventail Connect's Application Exclusion
List."