Recent Changes - Search:

Softwares

.

Apache-http-server-version-documentation

Main.Apache-http-server-version-documentation History

Hide minor edits - Show changes to output

Changed lines 97-99 from:

Sending the TERM or stop signal to the parent causes it to immediately attempt to kill off all of its
children.
to:
Sending the TERM or stop signal to the parent causes it to immediately attempt to kill off all of its children.
Added lines 100-101:

Graceful Restart
Deleted lines 102-105:


Graceful Restart
Changed line 106 from:
to:
Changed lines 98-100 from:
Sending the TERM or stop signal to the parent causes it to immediately attempt to kill off all of its children. It may take it several seconds to complete killing off its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are served.
to:
Sending the TERM or stop signal to the parent causes it to immediately attempt to kill off all of its children.

It
may take it several seconds to complete killing off its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are served.
Changed lines 110-112 from:
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.
to:
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.
Added lines 76-110:

In order to '''stop or restart Apache''', you must send a signal to the running httpd processes. There are two ways to send the signals. First, you can use the unix kill command to directly send signals to the processes. You will notice many httpd executables running on your system, but you should not send signals to any of them except the parent, whose pid is in the PidFile. That is to say you shouldn't ever need to send signals to any process except the parent. There are four signals that you can send the parent: TERM, USR1, HUP, and WINCH


To send a signal to the parent you should issue a command such as:

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

The second method of signaling the httpd processes is to use the -k command line options: stop, restart, graceful and graceful-stop, as described below. These are arguments to the httpd binary, but we recommend that you send them using the apachectl control script, which will pass them through to httpd.

After you have signaled httpd, you can read about its progress by issuing:

tail -f /usr/local/apache2/logs/error_log

Modify those examples to match your ServerRoot and PidFile settings.

Stop Now

Signal: TERM

'''apachectl -k stop'''

Sending the TERM or stop signal to the parent causes it to immediately attempt to kill off all of its children. It may take it several seconds to complete killing off its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are served.



Graceful Restart

Signal: USR1

'''apachectl -k graceful'''

The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.
Changed lines 66-67 from:
If Apache suffers a fatal problem during startup, it will write a message describing the problem either to the console
or to the ErrorLog before exiting. One of the most common error messages is "Unable to bind to Port ...". This message is usually caused by either:
to:
If Apache suffers a fatal problem during startup, it will write a message describing the problem either to the console or to the ErrorLog before exiting. One of the most common error messages is "Unable to bind to Port ...". This message is usually caused by either:
Changed lines 68-77 from:
* Trying to start the server on a privileged port when not logged in as the root user; or
* Trying to start the
server when there is another instance of Apache or some other web server already bound to the same Port.


The apachectl
script is designed to act like a standard SysV init script; it can take the arguments start, restart, and stop and translate them into the appropriate signals to httpd. So you can often simply link apachectl into the appropriate init directory.
The default location of the error log is /usr/local/apache2/logs/error_log, but see
the ErrorLog directive in your config files for the location on your server.


'''
Apache Laout:''' Please check http://wiki.apache.org/httpd/DistrosDefaultLayout
to:
Trying to start the server on a privileged port when not logged in as the root user; or Trying to start the server when there is another instance of Apache or some other web server already bound to the same Port.


The apachectl script is designed to act like a standard SysV init
script; it can take the arguments start, restart, and stop and translate them into the appropriate signals to httpd. So you can often simply link apachectl into the appropriate init directory. The default location of the error log is '''/usr/local/apache2/logs/error_log''', but see the ErrorLog directive in your config files for the location on your server.


'''Check
Apache Laout:''' Please check http://wiki.apache.org/httpd/DistrosDefaultLayout
Changed lines 2-3 from:
(:Googlemmm:)
to:
(:Googletxt:)
----
Changed lines 8-12 from:
'''New Features''' http://httpd.apache.org/docs/2.2/new_features_2_2.html

'''How to install''' http://httpd.apache.org/docs/2.2/install.html

Overview From apache.org
to:
'''New Features : ''' http://httpd.apache.org/docs/2.2/new_features_2_2.html

'''How to install : ''' http://httpd.apache.org/docs/2.2/install.html

'''Overview From apache.org'''
Changed line 34 from:
to:
----
Added lines 36-38:
----

The first step in upgrading is to read the release announcement and the file CHANGES in the source distribution to find any changes that may affect your site. When changing between major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), there will likely be major differences in the compile-time and run-time configuration that will require manual adjustments. All modules will also need to be upgraded to accomodate changes in the module API.
Deleted lines 39-40:
The first step in upgrading is to read the release announcement and the file CHANGES in the source distribution to find any changes that may affect your site. When changing between major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), there will likely be major differences in the compile-time and run-time configuration that will require manual adjustments. All modules will also need to be upgraded to accomodate changes in the module API.
Changed lines 54-55 from:
(:Googlemmmm:)
(:Google1:)
to:
(:Googlemmm:)
(:Google1:)

The recommended method of invoking the httpd executable is to use the apachectl control script. This script sets certain environment variables that are necessary for httpd to function correctly under some operating systems, and then invokes the httpd binary. apachectl will pass through any command line arguments, so any httpd options may also be used with apachectl. You may also directly edit the apachectl script by changing the HTTPD variable near the top to specify the correct location of the httpd binary and any command-line arguments that you wish to be always present.

The first thing that httpd does when it is invoked is to locate and read the configuration file httpd.conf. The location of this file is set at compile-time, but it is possible to specify its location at run time using the -f command-line option as in

/usr/local/apache2/bin/apachectl -f /usr/local/apache2/conf/httpd.conf

If all goes well during startup, the server will detach from the terminal and the command prompt will return almost immediately. This indicates that the server is up and running.


If Apache suffers a fatal problem during startup, it will write a message describing the problem either to the console
or to the ErrorLog before exiting. One of the most common error messages is "Unable to bind to Port ...". This message is usually caused by either:

* Trying to start the server on a privileged port when not logged in as the root user; or
* Trying to start the server when there is another instance of Apache or some other web server already bound to the same Port.


The apachectl script is designed to act like a standard SysV init script; it can take the arguments start, restart, and stop and translate them into the appropriate signals to httpd. So you can often simply link apachectl into the appropriate init directory.
The default location of the error log is /usr/local/apache2/logs/error_log, but see the ErrorLog directive in your config files for the location on your server.


'''Apache Laout:''' Please check http://wiki.apache.org/httpd/DistrosDefaultLayout

(:Google1:)
(:Googlemm:)
Added lines 1-54:
(:Google1:)
(:Googlemmm:)

'''Apache HTTP Server Version 2.2 Documentation'''

The documentation Tree is available at : http://httpd.apache.org/docs/2.2/

'''New Features''' http://httpd.apache.org/docs/2.2/new_features_2_2.html

'''How to install''' http://httpd.apache.org/docs/2.2/install.html

Overview From apache.org

Download $ lynx http://httpd.apache.org/download.cgi
$ gzip -d httpd-NN.tar.gz
Extract $ tar xvf httpd-NN.tar
$ cd httpd-NN
Configure $ ./configure --prefix=PREFIX
Compile $ make
Install $ make install
Customize $ vi PREFIX/conf/httpd.conf
Test $ PREFIX/bin/apachectl -k start

NN must be replaced with the current version number, and PREFIX must be replaced with the filesystem path under which the server should be installed. If PREFIX is not specified, it defaults to /usr/local/apache2.
Each section of the compilation and installation process is described in more detail below, beginning with the
requirements for compiling and installing Apache HTTP Server.

To configure the source tree using all the default options, simply type ./configure. To change the default options, configure accepts a variety of variables and command line options.

The most important option is the location --prefix where the Apache HTTP Server is to be installed later, because Apache HTTPd has to be configured for this location to work correctly. More fine-tuned control of the location of files is possible with additional configure options.

Also at this point, you can specify which features you want included in Apache HTTPd by enabling and disabling modules. The Apache HTTP Server comes with a Base set of modules included by default. Other modules are enabled using the --enable-module option, where module is the name of the module with the mod_ string removed and with any underscore converted to a dash. You can also choose to compile modules as shared objects (DSOs) -- which can be loaded or unloaded at runtime -- by using the option --enable-module=shared. Similarly, you can disable Base modules with the --disable-module option. Be careful when using these options, since configure cannot warn you if the module you specify does not exist; it will simply ignore the option.


'''Upgrading'''

The first step in upgrading is to read the release announcement and the file CHANGES in the source distribution to find any changes that may affect your site. When changing between major releases (for example, from 1.3 to 2.0 or from 2.0 to 2.2), there will likely be major differences in the compile-time and run-time configuration that will require manual adjustments. All modules will also need to be upgraded to accomodate changes in the module API.

Upgrading from one minor version to the next (for example, from 2.2.55 to 2.2.57) is easier. The make install process will not overwrite any of your existing documents, log files, or configuration files. In addition, the developers make every effort to avoid incompatible changes in the configure options, run-time configuration, or the module API between minor versions. In most cases you should be able to use an identical configure command line, an identical configuration file, and all of your modules should continue to work.

To upgrade across minor versions, start by finding the file config.nice in the build directory of your installed server or at the root of the source tree for your old install. This will contain the exact configure command line that you used to configure the source tree. Then to upgrade from one version to the next, you need only copy the config.nice file to the source tree of the new version, edit it to make any desired changes, and then run:

$ ./config.nice
$ make
$ make install
$ PREFIX/bin/apachectl -k graceful-stop
$ PREFIX/bin/apachectl -k start


You should always test any new version in your environment before putting it into production. For example, you can install and run the new version along side the old one by using a different --prefix and a different port (by adjusting the Listen directive) to test for any incompatibilities before doing the final upgrade.


(:Googlemmmm:)
(:Google1:)
Edit - History - Print - Recent Changes - Search
Page last modified on February 21, 2008, at 08:09 PM