Chapter 11

Processes and Services

The process and process management were introduced in Chapter 4. In this chapter, the user’s control of the process is covered from the perspectives of a Windows 7 user and a Red Hat Linux user. Starting processes, monitoring processes, scheduling processes, and terminating processes are all covered. The chapter then examines the role of the service as a component of the operating system. Common services are examined followed by configuring services in Linux. Finally, automating service startup at system initialization is covered for both Windows 7 and Red Hat Linux.

The learning objectives of this chapter are to

• Describe the steps in starting, controlling/managing, and terminating processes in Windows 7 and Red Hat Linux.
• Introduce process scheduling through the Windows Task Scheduler and the Linux commands at, batch, and crontab.
• Discuss the role of the service in support of operating systems.
• Describe the process of configuring Linux services.
• Discuss how to control service startup in both Windows 7 and Linux.

The process was introduced in Chapter 4. In this chapter, we examine how users and system administrators control their processes. We also look at operating system (OS) services, which are background processes that can also be controlled by the system administrator.

Starting a Process

To run a program, the program must be an executable—that is, the program must be available in the computer’s machine language. As most programs are written in a high level language (e.g., Java, C++), the programmer must translate the program from the high level language version into machine language. This is typically accomplished by using a program called a compiler. The compiler provides an executable version of the program as its output. You must compile the program for each platform that the program is intended to run on (e.g., a separate compilation is needed for a Macintosh, a Windows machine, a Linux machine, a mainframe).*

The first step in starting any process is to have the executable version of the program available. The executable program is stored somewhere in the file system (usually on hard disk, but it is also possible to run programs that are stored on optical disk, flash drive, etc.). When the user wishes to run a program, the OS must locate the executable program. In most OSs, the user indicates that a program should run through one of several possible approaches.

First, there may be shortcut icons. The shortcut icon is a graphical representation of a link to the program (recall soft links in Chapter 5). Double clicking on the shortcut causes the OS to start the program. Link’s properties include the file’s location in the file system. In Windows, you can view the properties of a shortcut by right clicking on the shortcut icon and selecting Properties.

See Figure 11.1 for an example of a shortcut to the program Gimp (an open source graphical editor). There are several tabs in the shortcut’s properties window. The General tab contains the location of the shortcut icon itself, whereas the Shortcut tab contains the location of the file’s executable program in a box called Target. The shortcut itself is stored in the current user’s Desktop, whereas the executable is located under the Program Files directory in a Gimpin subdirectory. Double clicking on the shortcut icon causes the OS to launch the program as stored in the Target location. Notice that the Target box is editable so that you can change the location of the executable if desired. The Security tab also contains useful information; it has the file permissions for the shortcut icon (these permissions should match the permissions of the executable itself).

To start a program, you can also double click on a data file created by that program. Usually, name extensions (e.g., .docx, .pdf, .mp3) are mapped to applications. Double clicking on the data file causes the OS to follow this mapping to the appropriate application software. That application software is started and the file is opened in the application software.

Most OSs also provide a program menu. Much like the shortcut icons, the program menu items store the target location of the executable program. In Windows, right clicking on the program name in the program menu and selecting properties brings up the same window as shown in Figure 11.1.

Linux has program menus and shortcut icons, just as in Windows. However, from Linux (as well as DOS) you can start a process from the command line. In reality, whether starting a program from a desktop icon, a program menu, or the command line, they all accomplish the same task in the same way. From the command line, however, you can provide optional and additional parameters. In most cases, the target location for the shortcut does not include parameters (although it could if desired). For instance, in Linux, you might specify vi –l someprogram.lsp. The –l option starts vi in “Lisp mode” to support editing Lisp programs. Additionally, by providing the filename in the command, vi opens with file already loaded.

Once you have issued your command to start a program, the OS takes over. First, it must locate the executable code stored in the file system. The directory listing will contain a pointer to the starting location of the program (disk block). Next, the OS must load the executable code into swap space, and copy a portion of the executable code (usually the first few pages) into memory. If memory has no free frames, the OS selects some frames to remove. The OS generates a page table for the process, and creates a process ID (PID) and a data structure that describes the process status and inserts it into a queue (ready or waiting, depending on processor load and process priority). The processor will eventually get to the process and begin executing it. This may be immediate or may take a few milliseconds depending on what other processes are being executed at the time.

In Linux (and Unix), processes are either parent processes or child processes (or both). A process that starts another process is known as the parent process. A process started by another process is known as a child process. As an example, if you are in a terminal window and you enter a command to start a process, say vi, then the terminal window process is the parent, and the process started, vi in this case, is the child. In Linux, only process 1, the process created when the system boots, is not a child process. All other process are child processes but may also be parent processes. The sidebar on the next page and the sidebar in Process Execution provide more detail on child and parent processes, and how they relate to each other.

In Windows, processes are not thought of as parents and children, although there may be a relationship if one process spawns another. In such a case, the spawned process is in the original process’s process tree. We will use this to control how to kill off processes (covered later in this chapter).

Process Execution

During execution, the user is largely uninvolved with controlling the process’ execution. The user can suspend a process, kill a process, move a process from foreground to background (or background to foreground), and change the process’ priority. Otherwise, the process’ execution is in the hands (or control) of the OS.

You might recall from Chapter 4 that a foreground process is one that can receive interaction with the user. The foreground actually represents two different notions. First, the foreground process is the process that is receiving interaction with the user. In both Windows and the graphical user interface (GUI) of a Linux OS, the foreground process is the process whose window is “on top” of other processes. This window is sometimes noted by having a different colored title bar. In Windows 7, you can tell the difference because the tab in the task bar for the process is somewhat illuminated, and the process’ window itself has a red “X” in the upper right hand corner. Figure 11.2 compares the foreground versus background processes showing both the task bar and the windows (look in the upper right-hand corner of the Word document).

The other notion of foreground processes is more accurate. The foreground processes are those that are in the ready queue. That is, the foreground processes are those that the CPU is multitasking through. The background processes then are those that are of low enough priority that they wait until the CPU is freed of foreground processes before the CPU executes them. Here, we will primarily concentrate on the former notion of foreground.

To move a background process to the foreground in a GUI, select its tab, or if the window is visible on your desktop, click in the window. To move a foreground process to the background, click on the minimize button in its window, or select another process to move to the foreground.

Now, consider running multiple processes in a terminal window in Linux rather than in the GUI. Since you are using the terminal window, there are no tabs to select; there is no way to minimize a process. This would seem to indicate that in a terminal window, you can only run one process at a time. This, however, is fortunately not the case. The idea of foreground and background in a terminal window is controlled by a few simple operations.

First, you can launch a process in the foreground by just entering the command’s name, as we have seen throughout the textbook. For instance, vi <enter> or grep … <enter> or top <enter> all launch the given program into the foreground for this terminal window. To start a process in the background, issue the command followed by an ampersand (&). For instance, if you feel that your grep command might take a lot of system resources and so you do not want it to interfere with the performance of the system, you might issue it as grep … & <enter>. The & forces the process to run in the background.

You can also force a process to switch from foreground to background or background to foreground. The commands are fg and bg, respectively. However, if a process is currently running a terminal window, you may not have access to the command line in order to issue the fg or bg command. To gain access to the command line prompt while a process is running in that window, type control+z. This suspends the running process and returns control of the shell to you.

For example, you issue the command top (top is explored in the next section). This is an interactive program. It fills the window with a display and updates itself so that you do not have access to the command line. Now, imagine that you press control+z. At this point, you would see:

[1]+ Stopped	top

This is telling you that job 1, top, is in a stopped state. At the command line, if you type jobs, you will see a list of all running and suspended jobs. If there is only one job, typing fg will resume that job in the foreground and typing bg will resume that job in the background.

Imagine that when you typed jobs, you instead saw the following:

> jobs

[1]– Stopped	top

[2]+ Stopped	vi

Here, there are two suspended jobs. If you type fg (or bg), the job selected is the one with the +, which indicates the most recently executing job. However, with the two numbers, you can also specify which job to move to the foreground or background by using fg n or bg n, where n is the job number. Both of these processes are interactive, so it makes little sense to move either to the background. However, you could easily resume one, suspend it, resume the other, suspend it, and resume the first, if for instance you were editing a document but wanted to, from time to time, see how the system was performing.

Consider, as another example, that you have two time-intensive jobs, and an editing job. You issue a find command that will search the entire file system, and a grep process that will have to search thousands of files. Both could take seconds or minutes. So you also want to edit a document in vi. You issue the following three commands:

> find …

 control+z

> bg 1

> egrep …

 control+z

> bg 2

> vi

Now you are editing in vi while both find and egrep run in the background. The steps here accomplish your task, but you could also more simply enter

> find … &

> egrep … &

> vi

Note that later in this chapter, we will examine another way to control a process—through its PID. The job number as used here is a different value. You obtain job numbers through the jobs command. You obtain PIDs through the ps or top command (covered in the next section).

In Linux, you can control a process’ priority using a command called nice. The nice command refers to a process’ niceness. Niceness, in Linux, is defined as how nice a process is toward other processes. The nicer a process is, the more it is willing to give up control of the CPU for other processes. In other words, a nicer process has a lower priority than a less nice process. The nice value ranges from –20 (least nice, or highest priority) to +19 (most nice, or lowest priority).

The nice command is issued when you launch a process from the command line, using the following format:

nice process-name –n value

This executes process-name establishing its initial nice value to value. If you do not issue a command using nice, it is given the default nice value of +10. Once a process is running, you can change its nice value using the exact same command.

For instance, if we launch some process foo issuing the command

nice foo –n 0

we can later adjust foo by issuing the command

nice foo –n 19

If you issue the nice command with no process or value, nice responds with the default nice value.

Process Status

A process’ status is information about the process. It will include its state, the resources granted to it, and its PID. Both Windows and Linux allow you to investigate your processes. You can find, for instance, how much CPU time each process uses, how busy your processor is, and how much main memory and virtual memory are currently in use. You can also control your process’ priority, adjusting the time the CPU will focus on the process during multitasking. Here, we look at the approaches used to probe the processor for process information.

In Windows, system performance and process status information is all available through the Windows Task Manager. The typical view is to look at the running applications (as opposed to the processes themselves). In Figure 11.3, we see that there are seven user applications currently running but 74 total processes (many of the processes are either system processes or were launched in support of the user applications). The CPU usage is 0% at the moment and physical memory is 28% (i.e., only 28% of memory is being used).

Under the Applications tab, there is little you can do other than start a new process, kill a process (End Task), or force the OS to switch from one process to another. In fact, by using “Switch To”, you are merely moving a process from the background to the foreground while the current foreground process is moved to the background. If you select New Task…, a pop-up window appears. In this window, you enter the name of the command you wish to execute. The command must include the full path to the executable file, for instance “C:Program FilesInternet Exploreriexplore.exe”. If you execute a process in this way, the process executes under administrator privileges.

The most important use of the Applications tab of the task manager is to kill a task that has stopped responding. Windows uses the expression “stopped responding” as a polite way to say that a process is deadlocked or otherwise has died but the OS cannot kill it off itself. To kill the process, highlight it in the list of processes and select End Task. If the application has unsaved data, you will be asked if you wish to save the data first.

The Processes tab provides far greater information than the applications tab. First, all of the processes are listed. Second, you see each process’ current CPU and memory usage. You also see who owns the process (who started it). In Windows, you will commonly see one of four users: SYSTEM, LOCAL SERVICE, NETWORK SERVICE, or your own user name. The first three indicate that either the OS started the process or that the process was spawned in support of other software (see Figure 11.4).

If you select any of the processes in the Processes tab, you can then right click on it and set the process’ priority (raise or lower it) and affinity (which processors or cores are allowed to run the process). Priorities are limited to one of six values: low, below normal, normal, above normal, high, and real time. The default for a process is normal. Real time signifies that the process is so important that it must complete its task as it is presented, that is, that it should never be postponed. You can also end the process, end the process as well as all processes that it may have spawned (end process tree), debug the process, or bring up the process’ properties. An example process properties window is shown in Figure 11.5. Here, you can see general information (type of file, description, location in the file system, size), change the process’ security, obtain details about the process, or find out the process’ compatibility.

The Services tab of the Task Manager is similar to the Processes tab except that it lists only services. The services are listed by PID, description, status, and group. If you click on any service, you can start or stop it. You can also obtain a list of all system services. We will explore services in detail in Services, Configuring Services, and Establishing Services at Boot Time.

The next two tabs of the Task Manager, Performance and Networking, provide system-specific information about resource utilization. Performance specifically covers CPU usage, main memory usage, virtual memory usage, and the current number of threads, processes, and handles running. A handle is a type of resource and might include open files, variables in memory, and pipe operations. Essentially, a handle is a pointer in a table to the actual entity that the handle represents. The Networking tab displays the current wireless and LAN connection usage (if any).

From the Performance tab, there is also a button to bring up Resource Monitor, which provides more details on CPU, Memory, Disk, and Network usage. Figure 11.6 displays both the Performance tab and the Resource Monitor window, displaying overall resource usage (notice the Resource Monitor has other tabs to isolate the usage of just CPU, memory, disk, or network). The final tab, Users, displays all users who are running processes. Typically, this will just be yourself, but it can show you if anyone else has remotely connected to your machine and is running any processes.

Using the resource monitor, you can select specific processes. This highlights their usage in the bottom-left portion of the window. In Figure 11.6, for instance, both firefox.exe (Mozilla Firefox web browser) and WINWORD.EXE (Microsoft Word) are highlighted and their memory usage is being displayed. Additional information is provided in this filter window, for instance, the amount of working memory, amount of memory in use that can be shared with other processes, and the amount of memory in use that is private to this process. Also being displayed in this filter window is the number of hard faults (page faults) that are occurring per second. You can similarly select the Disk or Network utilization for the selected processes.

There are a number of different tools for obtaining performance information in Linux. The more traditional means of obtaining information about a process is through the ps (process status) program, executed at the command line. The ps command has a number of options that might be confusing, so we will look at the more common options here.

Using ps by itself shows you the active processes in the current window owned by you. This may not be of sufficient value to a user as there are many processes that would not be shown to you, those owned by other users (including root), and those started outside of the given window. Table 11.1 provides a list of the more common options. Notice that in many cases, you do not use the – symbol when providing the options in the ps command. This is a departure from Unix where the – symbol was required.

Perhaps the most common usages of ps are ps by itself and ps aux. The ps aux version gives you all processes of all users. This may be too much information, however. You can pipe the result to grep to obtain only those processes that match a given string. For instance, ps aux | grep foxr would display only those processes owned by foxr, but would show all processes, not just those limited to the given terminal window. A variation of the options aux is axf, which gives you the processes in the shape of a tree to show you which processes spawned other processes. For instance, from bash you might type xterm to open a terminal window, and from that terminal window, you might issue another command (say to compile the current file); thus, bash is the parent of xterm, which is the parent of the compile command.

The ps command, when supplied with the parameter u, gives a long listing of information that includes for each process, the process’s owner, the PID, CPU usage, memory usage, terminal from which the command was issued, current process status, start time, and amount of CPU time that has elapsed. Note that obtaining the PID is particularly useful when you are faced with issuing other commands that impact a process. For instance, the kill command (covered in Terminating Processes) requires the PID for the process to be killed (terminated). Figure 11.7 demonstrates the ps command (top of figure) versus a portion of the output from the ps aux command (bottom of figure). As the ps aux command will display dozens of processes, it cannot be fully shown in one screen’s worth.

Another command to obtain status information is top. While ps provides a snapshot of what is going on at the time you issue the command, top is interactive in that it updates itself and displays the most recent information, usually every 3 seconds. Because top is interactive, it remains in the window and you do not have access to the command line prompt while it is executing. The ps command is not interactive—it runs, displaying all active processes and then returns the user to the command line. Another difference between ps and top is that top only lists the processes that are most active at the moment. There are a number of parameters that can allow you to change what top displays. For the most part, unless you are trying to work with the efficiency of your system, you will find ps to be easier and more helpful to use. To exit from top, type ctrl+c. Figure 11.8 demonstrates the top command’s output.

As with Windows, Linux also provides GUI tools for monitoring system performance. First, the System Monitor tool is akin to the Task Manager in Windows. The System Monitor has three tabs: to display processes, resource utilization, and the file system. Under the Processes tab, all processes are listed along with their status, CPU utilization, niceness, UID, and memory utilization. From here, you can stop or continue (wake up sleeping) processes, kill processes, or change their priority. The resources tab displays the CPU, memory, swap space, and network usage, both current and recent. The file systems tab displays the current mounted file system, similar to the df –k command. Figure 11.9 shows the processes and resources tabs.

In addition to the Resource Monitor, you can also view the background and on-demand services through the Service Configuration GUI. There is also a System Log Viewer GUI available. Although this does not provide direct information about running processes, many processes provide run-time information in log files. Log files are discussed later in the chapter along with services. Both the Service Configuration Manager and the System Log Viewer tools require that you log in as root to use them. This is not true for the System Monitor.

Scheduling Processes

The OS performs scheduling for us. There are a variety of forms of scheduling. In batch systems, scheduling was required to determine the order that the CPU would execute programs. As we tend not to use batch processing much today, this form of scheduling is one we can largely ignore. In multitasking, round-robin scheduling is the common approach to execute those processes in the ready queue. However, as discussed above, users can alter the behavior of round-robin scheduling by explicitly changing process priorities and/or moving processes to the background. Yet another form of scheduling that the OS performs is scheduling when processes are moved from a waiting queue to the ready queue. In personal computers, this is not typically relevant because all processes are moved to the ready queue. However, users may launch processes that place them into a waiting queue. Here, we focus on how to schedule processes in both Windows and Linux that indicate when a process should move to the ready queue.

Windows 7 provides the Task Scheduler program. See Figure 11.10. You are able to create scheduled actions to execute. Tasks can be scheduled for daily, weekly, or monthly activity, or a one-time occurrence. In any of these cases, you specify the starting time. You can also specify that a task should occur when the computer is next booted, when a specific user logs in, or when a type of event is logged. The action is one of starting a program or script, sending an e-mail, or displaying a message. As an example, you may set up a task to run your antiviral software each time your computer is booted, or every night at 3 am. You might similarly write a program to perform a complete backup and schedule that program to execute once per week.

In Linux, there are three scheduling programs of note. All three of these run processes in the background; therefore, the processes require input from files or sources other than the keyboard. This might require that the command(s) be issued with proper redirection. The three processes are crontab, at, and batch. The batch command allows you to schedule processes that will execute once the CPU load drops below 80%. The at command allows you to schedule processes to run at specific times. The at and batch commands perform one-time execution of the scheduled processes. The crontab command instead is used for recurring scheduling. As the at and batch commands are related, we discuss them together, but keep in mind that batch will cause the processes to run when CPU load permits execution, and at will run the processes only at the scheduled time.

Both at and batch can accept the command(s) to execute from the command line or from a file. The format of batch is merely batch or batch –f filename. The format for at is at TIME or at –f filename TIME. TIME formats are discussed later. If you use the –f option, the file must list, one line at a time, the process(es) to run. Each process should be a Linux command, including any necessary redirection—for instance, cat foo1.txt foo2.txt foo3.txt | sort >> foo4.txt. If you do not use the –f option, then the program (both at and batch) will drop you into a prompt that reads at >. From this prompt, you enter commands, one line at a time, pressing <enter> after each command. You end the input with control+d. When done, you are given a message such as

job 5 at 2012-03-01 12:38

which indicates the job number and the time it was entered (not the time when it will run or the PID it will run under).

The TIME indicator for at can take one of several formats. First, you can enter the time using a simple HH:MM format, such as 12:35 to run the process at 12:35. Without specifying am or pm, the time is assumed to be military time†; thus 12:35 would be pm, whereas 00:35 would be am, or alternatively 1:35 would be am and 13:35 would be pm. You may include or omit the minutes, so you might specify 1:00 pm, 1 pm, 13:00 but not 13. There are also three special times reserved, midnight, noon, and teatime (4 pm).

The at command schedules the process(es) to run the next time the specified time is reached. For instance, if you specify noon and it is already 1:35 pm, the process(es) will run the next day at noon. You can also specify the date if it is not within the next 24 hours. Dates are provided using one of three notations, MMDDYY, MM/DD/YY, or DD.MM.YY, where MM is a two-digit month (as in 1 or 01 for January and 12 for December), DD is a two-digit date, and YY is a two-digit year. You can also specify either today or tomorrow in place of a date, as in 1:35 pm tomorrow.

An alternative to specifying a time and date is to use now + value. With now, you are able to specify how far into the future the process(es) should run. The value will consist of a count (an integer) and a time unit. You might specify now + 3 minutes, now + 2 hours, now + 7 days, now + 2 weeks, or now + 1 month. Notice that you are not allowed to specify seconds in the TIME value.

Once you have scheduled a task, you can inspect the scheduled task(s) by using atq. The atq instruction shows you all waiting jobs. The queue lists jobs scheduled by both at and batch. The atrm command allows you to remove jobs from the scheduling queue. If there is only a single job, atrm removes it. Otherwise, you must indicate the job number as in atrm 3 to remove the third scheduled job.

Both at and batch are programs to schedule jobs. The atd service (or daemon) monitors the scheduling queue to see if a process should be executed. It runs in the background, and at every minute, compares the current time to the times of the scheduled tasks. Services are discussed starting in Services.

The other Linux scheduler is called crontab. This program would be used to schedule a recurring task, such as one that occurs every Monday at 1 am or the first day of every month. In some ways it is like at, but it is more complicated. First, you must set up a cron file. The cron file specifies two things: the time/date/recurrence to be scheduled and the process to be scheduled. The time/date consists of five integer numbers or *. The five values, in order, represent the minute, hour, day, month, and day of week to be scheduled. Minute will be a number between 0 and 59, hour between 0 and 23 using military time, day of the month between 1 and 31, month between 1 and 12, and day of week between 0 and 6 (where 0 means Sunday, 6 means Saturday). The * is a wildcard, much as we saw in Bash, meaning “any time”.

Here are some examples specifying the time portion of a crontab file:

15	3	1	*	*	— the first day of every month, at 3:15 am

0	14	*	*	0	—every Sunday at 2 pm

30	*	*	*	*	— every hour at half past (e.g., 12:30, 1:30, 2:30)

0	0	12	31	*	—every December 31, at midnight

0	*	*	*	*	—every hour of every day

If you specify both a date (day and month) and day of the week, both are used. So, for instance:

0	0	15	*	0

will schedule for midnight every 15th AND every Sunday.

If you want to schedule multiple time periods other than specific dates and days of the week, you can list multiple entries for each time category, separating the entries with commas. For instance,

0,30	0,6,12,18	*	*	*

will schedule the task to occur daily at 12:00 am, 12:30 am, 6:00 am, 6:30 am, 12:00 pm, 12:30 pm, 6:00 pm, 6:30 pm. Another variant is if you want the recurrence to be within a specific time interval, for instance, every 15 minutes. This is specified using /15, as in

0/15	12	*	*	*

for 12:00 noon every day, recurring every 15 minutes until 1:00 pm.

You can also specify ranges such as

0	0	1-5	*	*

to execute every day from the 1st to the 5th of the month at midnight.

The second half of the crontab file is the list of commands to be executed. As the commands should fit on a single line in the file, you would either list a single command, or invoke a shell script. For instance, the entry:

0	0	1	*	*	./somescript –a < foo.txt

will schedule the execution of .somescript –a < foo.txt to occur at midnight, the first of every month. The script somescript is located in the current directory, and it receives an option (–a) and input from foo.txt.

The reason that you are limited to one line for each scheduled task is that crontab allows files that contain multiple scheduled entries, one per line. Therefore, you could schedule numerous processes at different times using a single crontab file. Consider the following entries in a crontab file.

0	0	*	*	0	./backup_script

0	0	*	*	2	./cleanup_script

0/10	*	*	*	*	./who_report

This requests that a backup program will run every Sunday at midnight, that a cleanup script will run every Tuesday at midnight, and that a script to report on who is logged in will run every 10 minutes of every hour of every day.

Writing the crontab file is the first step in scheduling tasks with crontab. The second is the issuing of the crontab process itself. The crontab process is invoked by the command crontab –f filename. Without this step, none of the tasks scheduled in the file will actually be scheduled. An additional option in crontab is –u username. This allows you to run the processes listed under a different user name; otherwise, the processes default to running under the user’s account. This is particularly useful if you have switched to root before issuing crontab. You would not normally want a crontab job to run as root unless you knew specifically that the processes required root access. Therefore, as root, it is best to use crontab –u username –f filename, where username is your own account.

As with atq and atrm, you can examine the queue of crontab jobs and remove them. You would do this using crontab –l and crontab –r to list and remove the waiting jobs, respectively. You can also use crontab –e to edit the most recent crontab job. As the atd daemon is used to run at and batch jobs, the cron daemon is used to run crontab jobs.

One last note. In order to safeguard the system, you can specify which users are allowed to use crontab, at, and batch, and which users are not. There are several /etc files to control this. These are /etc/at.allow, /etc/at.deny, /etc/cron.allow, and /etc/cron.deny.

Terminating Processes

There are multiple ways for a process to terminate. First, it may complete execution. Second, you may choose to stop it yourself. Third, the program may “die”—that is, abnormally abort its execution. Obviously, if a process terminates on its own once it completes execution, there is no need for the user to be concerned, nor are there any actions that the user must take. In the third case, there will usually be some kind of feedback to the user to indicate that a terminating error arose. In Windows, for instance, you may receive an error pop-up window. Or, the program’s output window may just disappear from the screen. In Linux, programs that abnormally terminate usually leave behind a file called core. The core file is a “core dump”, which is a snapshot of the process’ working memory when it terminates. A programmer might examine the core file for clues as to the problem.

It is the second possibility that is troubling. The process remains “active” but is no longer making any progress toward completion. This might be caused by a deadlock situation (see Chapter 4), or child processes that have stopped responding, or a situation where the OS itself has lost pointers to the process. In any event, the user must discover that the process is not responding and decide what to do about it.

In Windows, to stop a process, you can just close the window. For processes that are not responding, this may not work and so you would invoke the Task Manager and kill the application or the process through this GUI. If the process is running in a terminal window (Linux) or DOS prompt window (windows), you can try ctrl+c to stop it. In Linux, you can also use the resource monitor to select and kill the process. You can also use the kill command from the command line. First, you must obtain the process’ PID through the ps command. The kill command is kill level pid. The level determines how hard the OS should try to kill it. The highest level is –9 and should be used whenever possible. To kill a process, you must be the process owner or root. The command killall can kill all active processes. To use killall in this way, you must be root.

You may need to search through the running processes to see what is still running, and shut down processes that you no longer need. This is true in either Windows or Linux. Just because there is no icon pinned to the task bar does not mean that a process could not still be running. In Linux, processes are often difficult to keep track of when launched from a command line. An interesting historical note is that when MIT shut down their IBM 7094 mainframe in 1973, they found a low-priority process waiting that had been submitted in 1967! Whether this story is true is unknown.

Shutting down the entire system is an important step. You will need to shut down your computer after installing certain software (especially OS patches). Additionally, Windows 7 requires being shut down and restarted when it performs OS upgrades. Linux can perform upgrades to its OS without shutting itself down.

Shutting down your system also helps clean up your virtual memory—if you leave your system running for too long, it is possible that your virtual memory becomes fragmented causing poor performance. In Windows, it is important to reboot your OS occasionally (say at least once per week) because of corruption that can occur with the system as stored in virtual memory and main memory. Since Linux is more stable than Windows, reboots are less frequently needed.

How do you shut down your computer? Well, what you never want to do is merely shut it off. Both Windows and Linux have a shutdown sequence. It is important to follow it so that all processes and services can be shut down appropriately and so that all files will be closed. If you do not do this correctly, data files and system files can be corrupted resulting in problems in your OS over time.

In Windows, the shutdown process is taken care of through the Start button menu. The options are to shut down the system, reboot the system (restart), log off as current user, switch user while remaining logged in, or to put your system to sleep in either sleep mode or hibernate mode. Sleep mode is a power saver mode that allows you to start back up rapidly. Hibernate is a longer term mode—you would use hibernate when you do not expect to restart the computer again in the next hour or few hours. The shutdown routine is straightforward to use, although the process that shutdown will undertake is very complex in terms of the steps involved in actually shutting down both the OS and the hardware. Shutting down the machine can also be time consuming.

In Linux, you may use the GUI, or you can shut down the system through the command line by using the shutdown command. From the command line, shutdown accepts a parameter, -h, which causes the system to halt. Halting the system actually stops all of the machinery, whereas shutdown merely places you into a special mode that permits you to halt the system. In addition to –h, you must specify a time (in minutes) to denote when shutdown should occur. This gives you a “grace period” so that all users can log off in time. The command shutdown –h 10 means to shutdown and halt the system in 10 minutes. You may also wish to send a message to users and processes to warn them of the imminent shutdown. The message might be something like “warning, system shutdown in 10 minutes, kill all processes NOW and log out!” The –r option not only shuts the system down, but reboots it afterward.

Services

A service is a piece of OS software that provides a particular type of function. This makes it sound like any other OS component. There are several differences, however. First, a service may be running or stopped (or suspended) whereas the programs that make up the OS kernel remain running at all times. Second, a service is set up to work with any number of other agents—applications software, users, network communications, etc. Thus, a service might be thought of as software that can be called upon by unknown clients. The OS kernel instead handles requests from the user or running software, but not from unknown or remote clients. Third, services run in the background, without user intervention. Since services run in the background, services are not necessary for non-multitasking systems. For instance, consider a single tasking system, where either the OS is executing or the application software is executing. There is no background. But in a multitasking system, a service may be called upon from time to time.

Services may be started at boot time, they may be started based on some scheduling system, or they may be started (and stopped) by system administrators. In Linux, services are often referred to as daemons (pronounced demons), and their names often end with a d, for instance, the scheduling command, at, is controlled by a daemon known as atd. In Windows, they are known as Windows Services but unlike Linux, some Windows Services can run as a normal process, that is, execute in the foreground.

One advantage to having services in an OS is that a system administrator can tailor the environment by controlling which services run and which services do not run. For instance, there may be a need for a mail service if we expect that this computer will receive e-mail. However, if this is not the case, the e-mail service can be stopped so that it neither takes up memory space nor requires any CPU attention.

Additionally, the system administrator can control how the service runs. When a service is started, the service will likely read a configuration file. By altering the configuration file, you can control how that service works. We will explore some of the Linux configuration files in Configuring Services.

Another advantage of having services is that the services, if running, are placed in the background. Thus, a service only requires system resources when it is called upon to perform its service. So, for instance, a service does not wait in the ready queue and use CPU time. Only when the service must respond will it use the CPU.

In Windows, services have a couple of noteworthy features. First, they run in less privileged modes than the Administrator mode. For instance, they may run under Local Service or Network Service accounts. This provides the service with additional access rights over a typical user, but not the full access of the administrator. Also in Windows, services are compartmentalized so that they cannot influence other services. A service that has been compromised by virus or other form of intrusion will not impact other services. Finally, services are not allowed to perform operations on the file system, system registry, or computer network.

In Linux, most services are spawned by the init process, which is the first process started after Linux boots (see the section Establishing Services at Boot Time). Once the system has started, the system administrator is able to start (and stop) services on demand at any time, so those services started later are not spawned by init. Services are disassociated from terminals so that they run in the background not of a shell but of the entire OS. They are established as having the root directory as their working directory, and thus are not impacted by what file systems are mounted.

A service should not be confused with a server, although they are related concepts. We might say that all servers provide a service, but not all services are servers. One way to think of the distinction is that a server is a large-scale piece of software (probably many programs). The server may have a number of roles or accomplish many tasks within the service it provides. We also tend to think of a server (the software) running on a computer set aside to accomplish the service. We will discuss servers in more detail in Chapter 13.

There are a great number of services available in both Windows and Linux OSs. In Windows, one can view the active services, start and stop them, using the Task Manager. Figure 11.11 shows the Services tab of the Task Manager. Selecting a service allows you to then start or stop it.

In Figure 11.11, for instance, you can see such services as Netlogon, KeyIso, Power, and PlugPlay are running while services such as VaultSvc, EPS, and bthserv are stopped. The description column provides a brief description of the service, and for those running, the PID indicates which process started those services. In Figure 11.11, for instance, several processes were started by process 564. This is most likely the program lsass.exe. Process 708, which started the services Power and PlugPlay is svchost.exe. To obtain process PIDs, click on the process tab, and under view, select Select Columns. From here, you can select which columns should be viewable. PID is not viewable by default but you can make it viewable. Notice that services that are stopped do not have a PID listed.

At the bottom of the Services tab of the Task Manager Window is a Services… button. Clicking on this button starts the Services window (see Figure 11.12). In the Services window, you can view information about the service such as its description and whether it is started automatically or requires manual startup. You can also start the Services window by right clicking on the Computer desktop icon and selecting Manage, or by starting the Control Panel, selecting Administrative Tools, and from the list of tools, selecting Services.

From the Services window, right clicking on a service and selecting Properties (or selecting Properties from the Action menu or from the button bar) displays the service’s properties. See Figure 11.13. There are four tabs in this window: General, Log On, Recovery, Dependencies.

The General tab provides the service’s name, a description, its location in the file system, how it is started (in the case of DHCP Client, it is started automatically at boot time), its current status (if started, you can stop it and vice versa), and what parameters are supplied when it is started. DHCP Client does not start with any parameters.

Under Startup type, there are four options: Automatic (Delayed Start), Automatic, Manual, Disabled. These are self-explanatory except for the first one, which was introduced in Windows Vista. As not all automatic services are needed immediately upon system boot, services can be categorized by their importance. Lower priority services can be started automatically upon boot, but postponed until other, more important services are started. Those denoted by “Delayed Start” do not get started until the initialization scripts, processes, and services run. The intention here is to provide a faster boot process for the user. Once booted, as the system has time, the remaining automatic services are started. As an example, the Windows Search and Windows Update services use this setting because their immediate service will not be needed.

Services may require access to system or network resources. If this is the case, the service requires a log in (account name and password). The log in type is indicated under the Log On tab (you can also see this in the Services window as the rightmost column, Log On As). For instance, DHCP will log on under the name Local Service. Other choices are Network Service and Local System. Local Service and Network Service will most likely require a log in account and password, whereas Local Service will not.

The Recovery tab indicates how the OS should attempt to recover if the service fails. In Windows, there are three levels of failure: first failure, second failure, and subsequent failures. The tab contains choices for each level, the choices being “take no action”, “restart the service”, “run a program” (in which case you indicate the program and any program parameters), and “restart the computer”. Failures are counted since the last reset. By default, resets occur every day. The delay before a service restart may occur is also controllable. This value is set in minutes (from 0 upward).

The Dependencies tab lists the services on which this service depends, and the services that depend on this service. This indicates the services that need to be running for this service to run successfully, and if this service were to stop running, what other services would be impacted. For instance, the DHCP Client service relies on the Ancillary Function Driver for Winsock, NetIO Legacy TDI Support Driver, and Network Store Interface services, whereas WinHTTP Web Proxy Auto-Discovery Service relies on DHCP Client.

In Linux, the Service Configuration Tool (see Figure 11.14) lets you view, start, and stop services. This tool is a graphical means of interfacing with services that can also be controlled via the /etc/rc.d directories and command line instructions. Automatically starting services is explained in detail in Establishing Services at Boot Time.

When you select a service in this tool, you are given that service’s description and any services that might rely on the service (i.e., dependencies). For instance, the syslog service requires that both syslogd and klogd be running, as shown in the figure. You are also given the “run level” for the service. This is described in Establishing Services at Boot Time as well. Notice that this tool offers two tabs, Background Services and On Demand Services. Most Linux services are intended to run in the background. However, you can also establish on demand services. These services will run when requested and will automatically end (exit the system) when there is nothing remaining for them to do.

In Linux, you can also view the status of any given service, start, stop, or restart it from the command line. There are two ways to control services from the command line. The common way is through the service command, which is under /sbin. The format of the command is /sbin/service servicename command, where servicename is the name of the service, for instance, syslog, and the command is one of start, stop, restart, and status. The status command merely responds with the service’s status: running, stopped, dead. The other command line approach to controlling a service is to issue a command directly to the service itself. The sshd service, for instance, is stored in /etc/init.d. Therefore, you can also issue the command /etc/init.d/sshd start (or restart, stop, or status).

There are a great number of services in both Windows and Linux, and their roles can differ widely. There is no easy categorization of all of the services. A general list of types of services along with some programs that handle these service categories is presented below.

Logging services. Log files play a critical role in determining the cause of unusual or erroneous events. Both Windows and Linux have services that regularly log events, whether generated by the OS or application software or from some other source. Windows Event Log stores and retrieves event information. Windows uses six levels of events: Audit Failure, Audit Success, Information, Warning, Error, and Critical. The Event Viewer program allows you to view events logged by Windows Event Log. Log entries can arise from applications, hardware events, Internet Explorer events, Media Center events, Security issues, System events, and others. Figure 11.15 demonstrates a view of the Event Logger, with the list of warnings enumerated, and Figure 11.16 shows some of the logged events from Applications. In Linux, syslogd and klogd share the logging chores, syslogd logs normal system and application events, whereas klogd logs specific kernel events. The Linux service auditd collects security-related events and records them in the audit.log files. The Linux service netconsole logs logging attempts. Other software might create their own log files, or they might call upon syslogd. The various log files in Linux are stored under /var/linux unless otherwise specified.

Scheduling services. Users, particularly system administrators, will commonly schedule processes to execute at certain times. For instance, an antiviral program might be scheduled to run every night at midnight, or a backup utility might be scheduled to run once per week at a specific time. The Windows scheduler is called Task Scheduler. It is both a scheduler and a service. Linux has several scheduling programs: at, batch, crontab. The Linux services that support scheduling are anacron, to execute processes scheduled for boot time, crond to execute processes scheduled by crontab, and atd to execute processes scheduled by at and batch.

Network services. There are a number of different tasks involved in communicating over a computer network, so there are numerous network-related services. In Linux, there is the network service that configures all network interfaces at boot time. But then there are ISDN (Integrated Services Digital Network) for communication over the telephone system, nfsd (Network File System Daemon), nmbd (Network Message Block Daemon), ntpd (Network Time Protocol Daemon), snmptd (Simple Network Management Protocol Daemon), as well as services for a web server (httpd), ftp server (ftpd), ssh server (sshd), mail server (sendmail, fetchmail), and domain name server (named). In Windows, there are NTDS (Network Authentication Server), BITS (Background Intelligent Transfer Service), DNSCache and DNS (for DNS clients and servers), and NSIS (Network Store Interface Service) to collect routing information for active network interfaces, to name a few. In Windows, Workstation creates and maintains client network connections to remote servers. Other network services in Windows include Network Access Protection Agent, Network Connections, and Network Location Awareness.

Firewall and Internet services. In Linux, dnsmasq starts the DNS caching server and httpd is used to start and stop the default Apache web server. The services iptables and ip6tables control the default Linux firewall. The Linux nscd service handles password and group lookup attempts for running programs, caching results for future queries. This service is needed to support other network-based authentication services such as NIS and LDAP. In Windows, Base Filtering Engine manages the Windows Firewall and Internet Protocol security. DHCP Client registers and updates IP addresses and DNS records for the computer and DNS Client caches DNS names. If this service is stopped, name services continue through the DNS, but results are no longer cached for efficiency, and other services that explicitly depend on the DNS Client will fail. Similar to ncsd, the Windows service Netlogon maintains a secure channel between a computer and the domain controller for authenticating users and services.

File system. As with network services, there are many different tasks involved in file system services. In Linux, these include autofs and amd, which are used to automatically mount file system partitions; netfs, which mounts and unmounts any network file systems; and mdmonitor, which manages the software portion of a RAID storage device. In Windows, Block Level Backup Engine Service provides backup and recovery support on the file system.

Peripheral devices. Windows has a number of services to support peripheral devices. These include Audio Service to manage audio jack configurations, Bluetooth Support Service, and Plug and Play, which allows the computer to recognize newly attached devices with little or no user input. In Linux, CUPS (common Unix printing system) supports communication with printers. There are a number of services that all support BlueTooth management, including bluetooth, hidd, pand, and dund. The conman service performs console management. The gpm service adds mouse support for text-based Linux applications, for example, by permitting copy-and-paste actions via the mouse.

Miscellany. The Linux oddjobd service is interesting in that it supports applications that do not have their own privileges. For instance, if a program requires some operation to be performed, but does not have the proper privileges to execute the operation, the program can request it of the oddjobd service. In Windows, there are a number of diagnostic services available. There are also services to support such actions as parental controls. Both OSs provide power management services: ampd in Linux and Power in Windows. For instance, the ampd service monitors battery status and can be used to automatically shut down a computer when the battery is too low.

Configuring Services

When a service is started, it will usually read a configuration file. The configuration file specifies the properties by which the service will execute. For instance, the Linux firewall service will operate using a number of rules. These rules are specified in the configuration file. Typically, Windows services use .ini (initialization) files to store these specifications, although in some cases, they end in .cfg or have other or no extensions. In Linux, configuration files often end with the .conf extension although this is not always the case. Also, like Linux scripts, the use of # to begin a line in a configuration file indicates that the line is a comment and should be ignored by the software that reads the file.

To alter the behavior of a service, you must stop the service, edit the configuration file, and then restart the service. This should not be done lightly as a mistake in a configuration file might cause the service to malfunction or not function at all. Here, we concentrate on several Linux.conf files, examining their syntax and some of the changes that you might make. In Linux, most configuration files can be found in the /etc directory.

We will start with one of the Linux logging services, syslogd. This service logs events generated by application software and non-kernel portions of the OS. To be configured, syslogd needs to know three things:

1. What types of activity should be logged
2. What conditions require logging
3. Where the logging should occur

   The file /etc/syslog.conf describes this information. As it is merely a text file, the system administrator is free to edit the file, which will then impact what gets logged and where. Each line of this file describes one form of logging event. A logging event will comprise one or more sources (software), the level of priority that would cause the event to be logged, and the action to take place should the source provide a message at the given priority level. Multiple sources can be listed on a single line if the sources would all share the same log file.

   The format for any single entry is source.priority [;source.priority]* action. That is, each entry will be at least one source.priority, but can be any number of source.priority pairs as long as they are separated by semicolons. The use of the wildcard (*) in the syntax above means “0 or more copies” although we will see that we can use the * as the source, priority, and action. If used for either the source or the priority, the * indicates “any source” or “any priority level”. For instance, one might use auth.* to indicate any authorization message, regardless of the priority level. Or, to indicate any message whose priority level is emergency, we could specify *.emerg. The entry *.* would log any event by any software.

   The action portion of an entry is almost always a file name, indicating where the message should be logged. In most cases, the logs are saved under the /var/log directory. However, if the message log is in support of a particular piece of software, it is possible that a different location might be desired, such as a log subdirectory under the home directory of the software. Aside from specifying the location of the log file, an * can be used, which instead sends the message to all logged in users to an open terminal window. You can also control the terminal to output to by using /dev/tty1, for instance, to output to only terminal tty1s instead of any open window. Another alternate action is to pipe the log message to another piece of software. Such an entry might look like this: |exec /usr/local/bin/filter.

   There are several default sources. These include auth (user authentication services), cron (the cronjob scheduler), daemon (all standard services), kern (the Linux kernel), lpr (printer server), mail (mail server), syslog (the syslogd service), and user (programs started by the user). The user programs are denoted as local0–local7, allowing for eight additional programs that can have customized logging. There are nine levels of priority that range from generating log messages only when the there is a total system failure to as simple as generating log messages for every activity of the given piece of software. The nine levels are shown in Table 11.2.

   Table 11.2

   Nine Priority Levels Used by syslog.conf

   None	No priority
   Debug	Debugging messages, used by programmers while testing their programs
   Info	Informational messages about what the program is doing
   Notice	Noteworthy events
   Warning	Warnings about potential problems
   Err	Errors that arise during execution
   Crit	Messages that describe critical errors that will most likely result in the program terminating abnormally
   Alert	Messages that will describe errors that not only result in a program terminating abnormally, but may also impact other running programs
   Emerg	Messages about errors that may result in a system crash

   Figure 11.17 shows the contents of the syslog.conf file. The first entry specifies that any kernel message should be sent to /dev/console, which is the console of the host computer (this message would not be sent to remote login consoles or other windows). The second entry specifies numerous messages: all informational messages and all mail, authpriv, and cron messages with no priority. These are all logged to /var/log/messages. The third entry requires that all other authpriv messages (above the “no priority” priority level) are logged to /var/log/secure. Can you make sense of the remaining entries? The use of the “–” in an action preceding a file name, for instance, -/var/log/maillog in the figure, indicates that messages should not be synchronized.

   Figure 11.17

   

   Logging entries from /etc/syslog.conf.

   The Linux firewall requires a configuration file. This file is stored in /etc/sysconfig/iptables. Modifying this file allows you to add, change, and delete firewall rules. Each row of this file is a rule that dictates a type of message that should be accepted or rejected by the firewall software. The rules have a peculiar syntax. They begin with the type of rule, an append rule (–A) or a flush rule (–F). The flush rule deletes all of the rules in the selected table, so most or all rules will begin with –A.

   The next item in a rule is the name of the stream from which a message might arrive. Streams have generic names such as INPUT, OUTPUT, or FORWARD, or may be from a specific location such as fast-input-queue or icmp-queue-out. The examples below indicate the input stream RH-Firewall-1-INPUT.

   Next are the specific conditions that the rule is to match. These may include ports, types of TCP/IP messages, source or destination IP addresses, or protocols. For instance, --dport 50 indicates a message over port 50, whereas –p udp --dport 5353 indicates a message over udp destination port 5353 and –d 1.2.3.4 indicates a destination IP address of 1.2.3.4.

   The final entry in a rule is typically the action that the rule should apply when the rule matches a message. The most basic actions are ACCEPT, LOG, DROP, and REJECT. ACCEPT immediately stops processing the message and passes it on to the OS (i.e., past the firewall). The LOG action logs the message but continues processing rules in case other rules might match to specify further actions. DROP causes the message to be blocked, whereas REJECT blocks the message but also replies to the host sending the packet that the packet was blocked.

   What follows are a few example rules:

   -A RH-Firewall-1-INPUT --dport 50 –j ACCEPT

   -A RH-Firewall-1-INPUT –p udp --dport 5353 –d 224.0.0.251 –j ACCEPT

   -A RH-Firewall-1-INPUT –p tcp –m tcp --dport 631 –j ACCEPT

   Typically, the iptables file will end with a default rule. If previous rules specify messages to accept or log, then the following rule would be a “backstop” rule to reject all other messages.

   -A RH-Firewall-1-INPUT –j REJECT --reject-with icmp-host-prohibited

   The /etc/fstab file stores mount information. This is applied whenever the mount –a (mount all) command is issued. The configuration information lists each mount partition, mount point (directory), and specific information about that partition such as whether the partition has a disk quota on individual entries and whether the partition is read-only. For instance, one entry is

   LABEL=/home	/home	ext3	defaults	1 2

   This entry describes that the /home partition should be mounted at the directory /home, the partition’s type is ext3, the partition uses the default options, and has values 1 and 2, respectively for the dump frequency (archiving schedule) and pass number (controls the order that the fsck program checks partitions). Options can include ro (read only), rw (read–write), auto or noauto (whether the partition should be automatically mounted at boot time or not), and usrquota (to establish quotas on each user directory). The ext3 type is common in Linux systems. However, if the partition is mounted over the network using the network file system (nfs), an additional option is to include the IP address using addr= #.#.#.#, where the # signs represent the octets of the IP address.

   The /etc/resolv.conf file is one of the simplest configuration files. It stores the IP addresses of the domain name system servers (DNS) for the computer. Unlike the previous two example configuration files that comprised a number of rules in some unique syntax, this file consists of entries that look like:

   nameserver 10.11.12.13

   nameserver 10.14.15.16

   The resolv.conf file is used by numerous Linux programs. We discuss the DNS in Chapter 12.

   The mail server in Linux is sendmail. It has a number of configuration files. One, /etc/aliases, permits e-mail aliases to be established. For instance, addresses such as bin, daemon, adm, halt, and mail are aliased to root so that, if a message is sent to any of those locations, it is actually sent to root. Another sendmail configuration file is /etc/mail/sendmail.cf. However, it is advised that you should never directly edit this file. Instead, the file /etc/mail/sendmail.mc is a macro file. Editing it will allow you to generate a new sendmail.cf file. As sendmail is a very complex program, we will not examine this configuration file.

   One last /etc configuration file worth noting is ldap.conf. LDAP is a server used to perform network-based authentication. That is, given a network of computers, an LDAP server can be used to authenticate a user on any of the network computers. Although LDAP is far beyond the scope of this text, its configuration file is worth mentioning. The format of the LDAP configuration file is unlike the previous files where each entry was a rule or instruction to the program. Instead, the LDAP configuration file contains directives. There are many forms of directives, each of which accomplishes a different task in initializing the LDAP server. For instance, the base directive specifies a “distinguished” name for searching. Another directive, uri, declares IP addresses of various types for the domain sockets. Other directives specify time limits, ports, filters, naming contexts, naming maps, and so forth. What follows is an example of an ldap.conf file:

   uri ldap://127.0.0.1/

   ssl no

   tls_cacertdir/etc/openldap/cacerts

   pam_password md5

   Modifying a configuration file of a service does not automatically cause the service to accept those changes. In most cases, the service must be restarted. You can do this by either stopping the service and then starting it anew, or by using the restart command instead. In many cases, it is wise to stop the service before modifying the configuration file.

   Establishing Services at Boot Time

   We end this chapter by considering which services are started automatically at system initialization time and which are not. As described in Services, Windows services can be controlled through the Services tool. By selecting any service from this tool, you can start or stop the service. Through the service’s properties window, you can specify the startup type. The choices are Automatic (Delayed Start), Automatic, Manual, Disabled. As an Administrator, you can change the startup type of any or all services as you desire. For instance, if it is felt that Parental Controls should always be running at boot time, you can change its startup type from Manual to Automatic. Similarly, Bluetooth Support Service is something that you might want running. However, as users will not require the Bluetooth service the instant that the system boots, you might set this to start by Automatic (Delayed Start). In this way, the service starts shortly after system initialization as time permits.

   Linux similarly is set up to automatically start specific services at system initialization time, and the services that start can be adjusted by system administrators. However, unlike Windows, in Linux you can establish different startup services depending on the run level. There are seven run levels in Linux. These are shown in Table 11.3.

   Table 11.3

   Linux Run Levels

   Run Level	Description
   0	Halt—shuts down all services when the system will not restart
   1	Single-user mode—for system maintenance, operates as root without network capabilities
   2	Multiuser mode without network—primarily used for maintenance and testing
   3	Multiuser mode with network—text-based mode for normal operation
   4	Not used
   5	Multiuser mode with network and GUI—typical mode for normal operation
   6	Reboot—shuts down all services for system reboot

   When Linux first boots, it runs the script /etc/inittab. One of the first things that inittab establishes is the run level. A run level of 5, for instance, starts the OS in full GUI mode, whereas run level of 3 is full text mode and run level of 1 is single user text mode. With the runlevel established, services are started based on the runlevel. The inittab script executes the script /etc/rc.d/rc. This script takes care of several startup activities, but among them, it iterates through the directory /etc/rc.d/rc#.d, where # is the runlevel (for instance, rc5.d for runlevel 5).

   A look at /etc/rc.d/rc5.d shows a number of symbolic links. Each symbolic link has a name in the form of K##name or S##name. The K and S stand for “kill” and “start”, respectively. This letter denotes whether the rc script will kill or start the service at startup. The number denotes the order in which the service is started (or stopped). See Figure 11.18, which lists the symbolic links for runlevel 5. A comparison between the /etc/rc.d/rc5.d and /etc/rc.d/rc3.d directories will show the services needed for the GUI versus those that are not, whereas a comparison between the /etc/rc.d/rc3.d and /etc/rc.d/rc2.d directories will show the services needed for network communication versus those that are not.

   Figure 11.18

   

   The /etc/rc.d/rc5.d directory of startup services.

   As each item in this directory is merely a symbolic link, the rc script follows the link to the actual service. All services are stored in the directory /etc/rc.d/init.d. Figure 11.19 illustrates the subdirectory structure for the startup scripts. The /etc/rc.d directory also contains two additional scripts: rc.sysinit and rc.local. The rc.sysinit script initializes a number of system settings, sets up the keyboard for use, established environment variables, and performs other hardware configuration steps. The rc.local script is available for the system administrator to further tailor the initial environment. It only executes once all other initialization scripts are executed. This file is initially nearly empty to start with.

   Figure 11.19

   

   Structure of the /etc/rc.d directory.

   As a system administrator, you can further tailor the run levels by merely changing symbolic link names. For instance, if it is deemed by the system administration that the Bluetooth service will not be needed in run level 5, the system administrator could rename the symbolic link S25bluetooth under /etc/rc.d/rc5.d to K25bluetooth. That is, rather than starting the bluetooth service, it is killed. Of course, if you are unsure about this, it is best to leave these symbolic links alone. You can always start or stop services at a later point by using /sbin/service bluetooth start/stop.

   Further Reading

   See Further Reading section in Chapter 4 for a list of texts that describe Windows 7, Linux, and Unix OSs. Process management is often covered as a chapter or two within these texts. Additionally, texts that discuss system administration for each OS will cover details on service configuration. You can find additional texts on configuring your Windows 7 and Linux OSs in certification study guides. The following texts specifically deal with configuring Linux.

   • Crawley, D. The Accidental Administrator: Linux Server Step-by-Step Configuration Guide. Washington: CreateSpace, 2010.
   • LeBlanc, D. and Yates, I. Linux Install and Configuration Little Black Book: The Must-Have Troubleshooting Guide to Installing and Configuring Linux. Scottsdale, AZ: Coriolis Open Press, 1999.

Review Terms

Terminology introduced in this chapter:

Child process oddjobd (Linux)

Configuration file Parent process

Core dump PID

Daemon Priority

Delayed start (Windows) Process properties

Exec (Linux command) Process status

Executing (process) Process tree

Executable Rc#.d (Linux)

Firewall Rc.sysinit (linux)

Fork (Linux command) Recovery (Windows)

Inittab (Linux) Resources

Init.d (Linux) Run level (Linux)

Kill (a process) Scheduling

Logging Service

Logon type (Windows) Service dependencies

Log file Short cut icons

Niceness Shut down

Sleeping (process) Syslog.conf (Linux)

Spawn Task manager (Windows)

Startup level (Windows) Terminating (process)

Suspended (process) Waiting (process)

Syslog (Linux)

Review Questions

4. In Windows, how can you move a process from the foreground to the background? In Linux from the command line, how can you move a process from the foreground to the background?
5. What is the difference between ps, ps a, and ps ax? Between ps aux and ps afx?
6. When starting a program in Linux, what happens if you end the command with an &?
7. What does the Linux jobs command do? How does it differ from ps?
8. In Linux, how does a parent generating a child through fork differ from a parent generating a child through exec?
9. If process A has a higher priority than process B, what does that mean with respect to both processes executing in a multitasking system?
10. If you were to increase a Linux process’ niceness (make the nice value larger), does this raise or lower its priority?
11. You want to run a process at 3:45 pm tomorrow. How would you specify this using Linux’ at command? What if it was 3:45 pm on March 1, 2013?
12. You want to run a process using at. How would you specify 3 hours from now? Three days from now?
13. You want a process to run recurring every Friday the 13th. How would do this? What if you wanted to specify every Friday at noon? What about the 15th of every month at 6:45 pm?
14. What does it mean to kill a process? Explain how you can kill a process in Windows and in Linux.
15. Why is it important to properly shut down a computer through the operating system’s shut down routine rather than just turning it off?
16. What is a grace period when you use the Linux shutdown command?
17. How does a service differ from the operating system kernel?
18. How does a service differ from a server?
19. What does it mean that a service runs in the background?
20. In Windows, how can you determine which services are running? How can you stop a running service?
21. In Linux, how can you determine which services are running?
22. In Linux, what options can you specify in the services command?
23. In Linux, what is the difference between syslogd and klogd?
24. What is the difference between the anacron and crond services in Linux?
25. What is a configuration file? When you modify a configuration file, what happens to the running service? What do you have to do to have the changes made to the configuration file take effect?
26. What do the following entries in the syslog.conf file mean?

    cron.*		/var/log/cron

    authpriv.warn	|/usr/sbin/filter

    *.emerg		*

27. What is the difference between the Crit, Alert, and Emerg priority levels for messages?
28. What does ACCEPT and REJECT mean when listed in rules in the iptables configuration file?
29. What do the K and S mean in the file names found in the /etc/rc5.d directories?
30. What is the difference between Linux run level 3 and 5? Why might you choose 3 instead of 5?
31. There are directories in/etc for each of rc0.d, rc1.d, …, rc.6.d. What do each of these directories represent? What is the number used for?

    Discussion Questions

32. You have started a process in Windows. It does not seem to be running correctly. What should you do in order to determine if the process is running, inspect its status, and either fix it or kill it?
33. Repeat question #1 but assume Linux instead of Windows.
34. Under what circumstances might you increase the priority of a process? Under what circumstances might you decrease the priority of a process?
35. As a system administrator, do you have the authority to change other users’ process priorities? If your answer is yes, explain under what situations you should use this authority.
36. In Windows 7, bring up the resource monitor tool. Select the “Overview” tab. Explain the various types of information it is providing you.
37. Repeat #5 but select the “Memory” tab.
38. Repeat #5 but select the “Disk” tab.
39. Create a list of five tasks that you, as a system administrator, feel should be scheduled for off hours. For instance, you might want to perform an automated backup at 2 am every Sunday night.
40. Explore the list of log files that are generated from the syslog daemon. As a system administrator, which of those log files do you feel you should inspect daily? Which should you inspect weekly? Which would you not inspect unless you had a particular reason to? Give an explanation for your answers.
41. As a user, how important is it for you to understand how a firewall works and to alter its configuration? As a system administrator?
42. As a system administrator, under what circumstances might you alter the services that start at boot time in Windows? In Linux?
43. As a follow-up to question #11, how would you alter the services that automatically start up at boot time in Windows? In Linux?

---