Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 
iakovlev.org

5.1 Starting the Server in Multi-Process Mode

To start Apache manually, just run its executable. For example, on our machine, a mod_perl-enabled Apache executable is located at /home/httpd/httpd_perl/httpd_perl. So to start it, we simply execute:

panic% /home/httpd/httpd_perl/bin/httpd_perl

This executable accepts a number of optional arguments. To find out what they are (without starting the server), use the -h argument:

panic% /home/httpd/httpd_perl/bin/httpd_perl -h

The most interesting arguments will be covered in the following sections. Any other arguments will be introduced as needed.

5.2 Starting the Server in Single-Process Mode

When developing new code, it is often helpful to run the server in single-process mode. This is most often used to find bugs in code that seems to work fine when the server starts, but refuses to work correctly after a few requests have been made. It also helps to uncover problems related to collisions between module names.

Running in single-process mode inhibits the server from automatically running in the background. This allows it to more easily be run under the control of a debugger. The -X switch is used to enable this mode:

panic% /home/httpd/httpd_perl/bin/httpd_perl -X

With the -X switch, the server runs in the foreground of the shell, so it can be killed by typing Ctrl-C. You can run it in the background by appending an ampersand:

panic% /home/httpd/httpd_perl/bin/httpd_perl -X &

Note that in -X (single-process) mode, the server will run very slowly when fetching images. Because only one request can be served at a time, requests for images normally done in parallel by the browser will now be serialized, making the page display slower.

Note for Netscape Users

If Netscape is being used as the test browser while the server is running in single-process mode, the HTTP protocol's KeepAlive feature gets in the way. Netscape tries to open multiple connections and keep them all open, as this should be faster for browsing. But because there is only one server process listening, each connection has to time out before the next one succeeds. Turn off KeepAlive in httpd.conf to avoid this effect while testing. Assuming you use width and height image size parameters in your HTML files, Netscape will be able to render the page without the images, so you can press the browser's Stop button after a few seconds to speed up page display. It's always good practice to specify width and height image size parameters.

Also note that when running with -X, the control messages that the parent server normally writes to error_log (e.g., "server started", "server stopped", etc.) will not be written anywhere. httpd -X causes the server to handle all requests itself without forking any children, so there is no controlling parent to write the status messages.

Usually Ctrl-C is used to kill a server running in single process mode, but Ctrl-C doesn't constitute a clean shutdown. httpd.pid doesn't get removed, so the next time the server is started, the message:

[warn] pid file /home/httpd/httpd_perl/logs/httpd.pid
 overwritten -- Unclean shutdown of previous Apache run?

will appear in error_log. You can ignore this warning; there's nothing to worry about.

5.3 Using kill to Control Processes

Linux and other Unix-like operating systems support a form of interprocess communication called signals. The kill command is used to send a signal to a running process. How a process responds to a signal, if it responds at all, depends on the specific signal sent and on the handler set by the process. If you are familiar with Unix signal handling, you will find that Apache adheres to the usual conventions, and you can probably skip this section. This section describes the use of kill in relation to Apache for readers who aren't accustomed to working with signals.

The name "kill" is a misnomer; it sounds as if the command is inherently destructive, but kill simply sends signals to programs. Only a few signals will actually kill the process by default. Most signals can be caught by the process, which may choose to either perform a specific action or ignore the signal. When a process is in a zombie or uninterruptible sleep( ) state, it might ignore any signals.

The following example will help dispel any fear of using this command. Most people who are familiar with the command line know that pressing Ctrl-C will usually terminate a process running in a console. For example, it is common to execute:

panic% tail -f /home/httpd/httpd_perl/logs/error_log

to monitor the Apache server's error_log file. The only way to stop tail is by pressing Ctrl-C in the console in which the process is running. The same result can be achieved by sending the INT (interrupt) signal to this process. For example:

panic% kill -INT 17084

When this command is run, the tail process is aborted, assuming that the process identifier (PID) of the tail process is 17084.

Every process running in the system has its own PID. kill identifies processes by their PIDs. If kill were to use process names and there were two tail processes running, it might send the signal to the wrong process. The most common way to determine the PID of a process is to use ps to display information about the current processes on the machine. The arguments to this utility vary depending on the operating system. For example, on BSD-family systems, the following command works:

panic% ps auxc | grep tail

On a System V Unix flavor such as Solaris, the following command may be used instead:

panic% ps -eaf | grep tail

In the first part of the command, ps prints information about all the current processes. This is then piped to a grep command that prints lines containing the text "tail". Assuming only one such tail process is running, we get the following output:

root  17084  0.1  0.1  1112  408  pts/8  S  17:28  0:00  tail

The first column shows the username of the account running the process, the second column shows the PID, and the last column shows the name of the command. The other columns vary between operating systems.

Processes are free to ignore almost all signals they receive, and there are cases when they will. Let's run the less command on the same error_log file:

panic% less /home/httpd/httpd_perl/logs/error_log

Neither pressing Ctrl-C nor sending the INT signal will kill the process, because the implementers of this utility chose to ignore that signal. The way to kill the process is to type q.

Sometimes numerical signal values are used instead of their symbolic names. For example, 2 is normally the numeric equivalent of the symbolic name INT. Hence, these two commands are equivalent on Linux:

panic% kill -2 17084
 panic% kill -INT 17084

On Solaris, the -s option is used when working with symbolic signal names:

panic% kill -s INT 17084

To find the numerical equivalents, either refer to the signal(7) manpage, or ask Perl to help you:

panic% perl -MConfig -e 'printf "%6s %2d\n", $_, $sig++ \
                     for split / /, $Config{sig_name}'

If you want to send a signal to all processes wit