Starting and Stopping the Server and Monitoring Server Activities in Linux

Starting and Stopping the Server

The procedure for starting and stopping the Apache Web server is no different from that of many other server processes. You can use the chkconfig command to set the httpd service to start at boot time.

The /etc/init.d/httpd shell script accepts any of five command-line arguments. If it is called with the argument start, the httpd script will run one master daemon process (owned by "root"), which will spawn other daemon processes (equal to the number specified by the StartServers directive) owned by the user apache (from the User andGroup directives). These processes are responsible for responding to incoming HTTP requests. If called with stop, the server will be shut down as all httpd processes are terminated.

If given a command-line argument of restart, the script will simply execute stop and start procedures in sequence. Using reload as the argument will send the hangup signal (-HUP) to the master httpd daemon, which causes it to reread its configuration files and restart all the other httpd daemon processes. The shell script also supports an argument of status, which will report if the daemon is running and, if it is, the PIDs of the running processes. All other command-line arguments result in an error and cause a usage message to be printed.

Monitoring Server Activities

Apache provides two unique built-in methods to check the performance of your Web server. The server-status handler can be configured to show information about server processes. The server-info handler can be configured to display a detailed summary of the Web server's configuration. You can activate these services by adding the following lines to the /etc/httpd/conf/httpd.conf file, respectively:

<Location /server-status>

    SetHandler server-status

    Order deny,allow

    Deny from all

    Allow from handsonhistory.com

</Location>

<Location /server-info>

    SetHandler server-info

    Order deny,allow

    Deny from all

    Allow from handsonhistory.com

</Location>

In this example, all computers in the handsonhistory.com domain can display the server-info and server-status pages. You can changehandsonhistory.com to the name of any domain or host that your Apache server is hosting.

Displaying server information

The Server Information (server-info) page contains the server version information and various general configuration parameters and breaks up the rest of the data by module. Each loaded module is listed, with information about all directives supported by that module, and the current value of any defined directives from that module.

The Server Information is usually quite verbose and contains much more information than can be displayed in Figure 21-3, which shows only the links to each module's section and the general Server Settings section.

Figure 21-3: The server-info page displays server and module information.

Displaying server status

The contents of the server-status page include version information for the server, the current time, a timestamp of when the server was last started, and the server's uptime. The page also details the status of each server process, choosing from several possible states (waiting for a connection, just starting up, reading a request, sending a reply, waiting to read a request before reaching the number of seconds defined in the KeepAliveTimeout, performing a DNS lookup, logging a transaction, or gracefully exiting).

The bottom of the server-status page lists each server by process ID (PID) and indicates its state, using the same possible values. Figure 21-4 is an example of this page.

 
Figure 21-4: The Apache server-status page displays general Apache information and reports on individual server process activities.

 

 

Grub Intro and TroubleShooting in Grub

 a boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to an operating system kernel software (such as Linux or GNU Mach). The kernel, in turn, initializes the rest of the operating system (e.g. a GNU system).

GNU GRUB is a very powerful boot loader, which can load a wide variety of free operating systems, as well as proprietary operating systems with chain-loading. GRUB is designed to address the complexity of booting a personal computer; both the program and this manual are tightly bound to that computer platform, although porting to other platforms may be addressed in the future.
One of the important features in GRUB is flexibility; GRUB understands filesystems and kernel executable formats, so you can load an arbitrary operating system the way you like, without recording the physical position of your kernel on the disk. Thus you can load the kernel just by specifying its file name and the drive and partition where the kernel resides.

When booting with GRUB, you can use either a command-line interface , or a menu interface. Using the command-line interface, you type the drive specification and file name of the kernel manually. In the menu interface, you just select an OS using the arrow keys. The menu is based on a configuration file which you prepare beforehand . While in the menu, you can switch to the command-line mode, and vice-versa. You can even edit menu entries before using them.
 

GRUB features

The primary requirement for GRUB is that it be compliant with the Multiboot Specification, which is described in Multiboot Specification.
The other goals, listed in approximate order of importance, are:

• Basic functions must be straightforward for end-users.
• Rich functionality to support kernel experts and designers.
• Backward compatibility for booting FreeBSD, NetBSD, OpenBSD, and Linux. Proprietary kernels (such as DOS, Windows NT, and OS/2) are supported via a chain-loading function.

Except for specific compatibility modes (chain-loading and the Linux piggyback format), all kernels will be started in much the same state as in the Multiboot Specification. Only kernels loaded at 1 megabyte or above are presently supported. Any attempt to load below that boundary will simply result in immediate failure and an error message reporting the problem.
In addition to the requirements above, GRUB has the following features:

Recognize multiple executable formats

Support non-Multiboot kernels

Load multiples modules

Load a configuration file

Provide a menu interface

Have a flexible command-line interface

Support multiple filesystem types

Support automatic decompression

Access data on any installed device

Be independent of drive geometry translations

Detect all installed ram

Support Logical Block Address mode

Support network booting

Support remote terminals

 

Installing GRUB using grub-install

For information on where GRUB should be installed on PC BIOS platforms, see BIOS installation.
In order to install GRUB under a UNIX-like OS (such as gnu), invoke the program grub-install (see Invoking grub-install) as the superuser (root).
The usage is basically very simple. You only need to specify one argument to the program, namely, where to install the boot loader. The argument has to be either a device file (like ‘/dev/hda’). For example, under Linux the following will install GRUB into the MBR of the first IDE disk:

     # grub-install /dev/hda

Likewise, under GNU/Hurd, this has the same effect:

     # grub-install /dev/hd0

But all the above examples assume that GRUB should put images under the /boot directory. If you want GRUB to put images under a directory other than /boot, you need to specify the option --boot-directory. The typical usage is that you create a GRUB boot floppy with a filesystem. Here is an example:

     # mke2fs /dev/fd0

     # mount -t ext2 /dev/fd0 /mnt

     # mkdir /mnt/boot

     # grub-install --boot-directory=/mnt/boot /dev/fd0

     # umount /mnt

Some BIOSes have a bug of exposing the first partition of a USB drive as a floppy instead of exposing the USB drive as a hard disk (they call it “USB-FDD” boot). In such cases, you need to install like this:

     # losetup /dev/loop0 /dev/sdb1

     # mount /dev/loop0 /mnt/usb

     # grub-install --boot-directory=/mnt/usb/bugbios --force --allow-floppy /dev/loop0

This install doesn't conflict with standard install as long as they are in separate directories.
Note that grub-install is actually just a shell script and the real task is done by grub-mkimage and grub-setup. Therefore, you may run those commands directly to install GRUB, without using grub-install. Don't do that, however, unless you are very familiar with the internals of GRUB. Installing a boot loader on a running OS may be extremely dangerous.
 

Troubleshooting:

Error messages produced by GRUB

 GRUB only offers a rescue shell
GRUB's normal start-up procedure involves setting the ‘prefix’ environment variable to a value set in the core image by grub-install, setting the ‘root’ variable to match, loading the ‘normal’ module from the prefix, and running the ‘normal’ command. This command is responsible for reading /boot/grub/grub.cfg, running the menu, and doing all the useful things GRUB is supposed to do.
If, instead, you only get a rescue shell, this usually means that GRUB failed to load the ‘normal’ module for some reason. It may be possible to work around this temporarily: for instance, if the reason for the failure is that ‘prefix’ is wrong (perhaps it refers to the wrong device, or perhaps the path to /boot/grub was not correctly made relative to the device), then you can correct this and enter normal mode manually:

     # Inspect the current prefix (and other preset variables):

     set

     # Find out which devices are available:

     ls

     # Set to the correct value, which might be something like this:

     set prefix=(hd0,1)/grub

     set root=(hd0,1)

     insmod normal

     normal

However, any problem that leaves you in the rescue shell probably means that GRUB was not correctly installed. It may be more useful to try to reinstall it properly using grub-install device. When doing this, there are a few things to remember:

• Drive ordering in your operating system may not be the same as the boot drive ordering used by your firmware. Do not assume that your first hard drive (e.g. ‘/dev/sda’) is the one that your firmware will boot from. device.map can be used to override this, but it is usually better to use UUIDs or file system labels and avoid depending on drive ordering entirely.
• At least on BIOS systems, if you tell grub-install to install GRUB to a partition but GRUB has already been installed in the master boot record, then the GRUB installation in the partition will be ignored.
• If possible, it is generally best to avoid installing GRUB to a partition (unless it is a special partition for the use of GRUB alone, such as the BIOS Boot Partition used on GPT). Doing this means that GRUB may stop being able to read its core image due to a file system moving blocks around, such as while defragmenting, running checks, or even during normal operation. Installing to the whole disk device is normally more robust.
• Check that GRUB actually knows how to read from the device and file system containing /boot/grub. It will not be able to read from encrypted devices, nor from file systems for which support has not yet been added to GRUB.