Service Management on Linux (RHEL)

On any system it is important to manage the running services. Managing services enables you to ensure the stability and reliability that your system will offer. A service can range from something simple, such as providing your local system with the correct time, or something more complex, such as sharing a file system over the entire network for your users using NFS. 

In Linux, services can also be called daemons. The reason for this is that some services are actually composed of multiple daemons. You can usually tell if something is a daemon because it (the service name) ends in a d. An example of this would be the SSH service (sshd) or the Apache web service (httpd). 

Let’s look at different runlevels and how they deal with services during the boot process. We start by looking in the /etc/rc.d/rc3.d directory (which correlates to runlevel 3): 

You wouldn’t know by looking at the output of this command, but these are all actually soft links to scripts on the system, usually within the /etc/rc.d/init.d directory. You can also see from the output that each link has an interesting syntax. The syntax is something like: 

The K stands for Kill and the S stands for Start. The ## are any number between 01 and 99, including duplicates. When you put all this together, you get a listing of every service that is either stopped (K) or started (S) when the system enters runlevel 3. The numbers indicate the order in which a service is stopped or started, with all Kills being processed first (in numerical order from 1 to 99). If the number order is the same, the alphabetical sort dictates the order. 

Now that you have an understanding of how the different services are stopped or started in different runlevels, we can look at the final management ultilities, which provide a means for enabling and disabling services at each runlevel. To ease the mangement of services at each runlevel, you can use the chkconfig command. 

Syntax: chkconfig [option] service_name

Options:

--list [name] Show the status of the service at each runlevel

--add <name> Adds a service to be managed by chkconfig command

--dell <name> Removes a service from being managed by the chkconfig comand

--level <levels> Enables or disables the service at given levels

<name> <on|off|reset> Enables or disables the service at level 2-5

The options for this command are little different than you would normally see for a utility. The easiest way tho explain how to use this command is through examples.

Aside from using the chkconfig command, you can accomplish all the same tasks by using the ntsysv command. The only difference is that ntsysv is menu driven, making it more visually appealing. To manage the different runlevels, you just call the ntsysv command with the runlevel(s) you want to manage. 

For example, if you want to manage services at runlevel 2, just type the command:

What happens when the system boots and you want to start a service that you forgot to include in the startup services? Do you have to use chkconfig command to add it and reboot the system? No. Aside from enabling and disabling services at system boot, you also can use the service command. You can use this to start, stop, and query the status of services on the system after it has already booted. 

One import thing that I want to to remember is in RHEL6, Upstart program uses jobs and events to run different services. Currently, you can find jobs located in the /etc/init directory, you can find events located in the /etc/event.d directory, and there are still the tradditional SysV Init directories. With the release of RHEL6, a few services have been moved over to use the new Upstart utility exclusively (such as the Syslog service, which is responsible for the system logs). Each job can include events that trigger additional jobs or system scripts. Let’s look at a sample job:

Aside from jobs, you can also define events:

Using the initctl command, you can view, start, and stop jobs much like the service command does.

Syntax: initctl [command]

Options:

start         Starts a job

stop         Stops a job

restart Restarts a job

reload Sends a HUP signal to a job

status Queries the status of a job

list           List known jobs

emit        Emits an event

You’ll notice that initctl is similar to the service command, but you can call both jobs and events. There aren’t many jobs or events on RHEL6 yet because the implementation of Upstart is new. Writing Upstart jobs and events isn’t too difficult, for more information, visit the following site:

http://upstart.ubuntu.com/

Have fun!