The following test objectives for Exam CX-310-200 are covered in this chapter

Explain how to view system processes and clear hung processes.

Explain how to schedule an automatic one-time execution of a command and the automatic recurring execution of a command.

The following study strategies will help you prepare for the test:

Exam Alert

This chapter covers Solaris processes—how to view processes, understand the effects signals have on processes, and how to manage processes.

Objective:

Explain how to view system processes.

Solaris is a multitasking environment in which a number of programs run at the same time. This means that many users can be active on the system at the same time, running many jobs (processes) simultaneously. Each Solaris program can start and stop multiple processes while it is running, but only one job is active per processor at any given time while the other jobs wait in a job queue. Because each process takes its turn running in very short time slices (much less than a second each), multitasking operating systems give the appearance that multiple processes are running at the same time. A parent process forks a child process, which, in turn, can fork other processes.

Note

A program can be made up of many processes. A process is part of a program running in its own address space. A process under Solaris consists of an address space and a set of data structures in the kernel to keep track of that process. The address space is divided into various sections that include the instructions that the process may execute, memory allocated during the execution of the process, the stack, and memory-mapped files. The kernel must keep track of the following data for each process on the system:

A process is distinct from a job, command, or program that can be composed of many processes working together to perform a specific task. For example, a computer-aided design application is a single program. When this program starts, it spawns other processes as it runs. When a user logs in to the program, it spawns yet other processes. Each process has a process ID associated with it and is referred to as a PID. You can monitor processes that are currently executing by using one of the commands listed in Table 5.1.

Before getting into the commands used to monitor processes, you first need to become familiar with process attributes. A process has certain attributes that directly affect execution. These are listed in Table 5.2.

Use the ps command to view processes currently running on the system. Use the ps command when you’re on a character-based terminal and don’t have access to a graphical display. Adding the -l option to the ps command displays a variety of other information about the processes currently running, including the state of each process (listed under S). The codes used to show the various process states are listed in Table 5.3.

To see all the processes that are running on a system, type the following:

The system responds with the following output:

The manual page for the ps command describes all the fields displayed with the ps command, as well as all the command options. Table 5.4 lists some important fields.

You often want to look at all processes. You can do this using the command ps -el. A number of options available with the ps command control what information gets printed. A few of them are listed in Table 5.5.

For a complete list of options to the ps command, refer to the Solaris online manual pages.

Note

Process Manager

In the Desktop Environment (CDE & JAVA Desktop) you have access to the Process Manager GUI, sdtprocess, a graphical tool that provides a process manager window for monitoring and controlling system processes.

Exam Alert

The exam will most likely ask you about the command-line tools used to manage system processes, such as kill, pkill, pargs, and pgrep. You only need to understand that GUI tools can be used to manage processes and you should be prepared to identify these GUI tools.

The advantage of using the Process Manager is that you can view and control processes without knowing all the complex options associated with the ps and kill commands. For example, you can display processes that contain specific character strings, and you can sort the process list alphabetically or numerically. You can initiate a search using the find command, or you can terminate a process simply by highlighting it and clicking kill.

To open the Process Manager, you need to log into the Desktop windowing environment. You can start the GUI by executing the command sdtprocess, as follows:

sdtprocess &

Or, you can click Find Process on the Tools subpanel, as shown in Figure 5.1.

Figure 5.1 Front panel.

The Process Manager window opens, as shown in Figure 5.2.

Figure 5.2 Process Manager window.

Each process attribute in the header of the Process Manager window provides detailed information about the process and is described in Table 5.10.

Table 5.10 Process Manager Window

Click any of the column headings to sort the processes by that attribute. For example, click the CPU heading to sort all processes by their CPU usage. The list updates every 30 seconds, but you can enter a value in the Sampling field to update the list as frequently as you like. Finally, you can enter a text string that is common to the process entries of all the processes you want to display in the Find drop-down menu. In Figure 5.3, I entered “root” in the Find field to display all processes owned by root. I also changed the sampling rate to every 5 seconds and clicked the CPU heading to sort processes by their CPU usage.

Figure 5.3 Sorted Process Manager window.

Another nice feature of the Process Manager is the capability to display the ancestry of a process. When a Unix process initiates one or more processes, these are child processes, or children. Child and parent processes have the same user ID. To view a parent process and all the child processes that belong to it, highlight the process in the Process Manager window. Click Process from the toolbar at the top of the window and select Show Ancestry, as shown in Figure 5.4.

Figure 5.4 Selecting Show Ancestry.

The window shown in Figure 5.5 displays showing all the processes belonging to the parent.

Figure 5.5 Show Ancestry window.

The command-line equivalent to the Ancestry selection in the Process Manager is the ptree command. Use this command when you don’t have a graphical display terminal. The ptree command displays the process ancestry trees containing the specified PIDs or users. The child processes are displayed indented from their respective parent processes. For example, here is the process tree for the -sh process, which has a PID of 293:

ptree 293

The system responds with this:

SMC Process Tool

The Solaris Management Console (SMC) includes a GUI called the Process Tool, which is used for viewing and managing processes, similar to the Desktop Process Manager tool described in the previous section. You can use the job scheduler tool to

   Suspend a process

   Resume a suspended process

   Kill a process

   Display information about a process

To open the Process Tool, follow Step by Step 5.1.

---

STEP BY STEP

5.1 Opening the Process Tool

1.   Start up the Solaris Management Console by typing

smc

2.   The SMC Welcome window appears as shown in Figure 5.6.

Figure 5.6 SMC Welcome Window.

3.   In the SMC navigation pane, open the Process Tool by clicking on the This Computer icon, then click on the System Status icon, then click on the Processes icon as shown in Figure 5.7.

Figure 5.7 Opening the Job Scheduler.

4.   The Process Tool displays as shown in Figure 5.8

Figure 5.8 Process Tool.

The Process Tool works much the same way as the Process Manager tool described earlier.

The pargs command is used from the command line to examine the arguments and environment variables of a process (or number of processes). pargs can also be used to examine core files.

The syntax for the pargs command is as follows:

Table 5.11 describes the pargs command options and arguments.

For example, use the pargs command to view all of the environment variables associated with the telnetd process, I first need to find the PID of the telnetd process using pgrep as follows:

Next, I issue the pargs command using the PID for the telnetd process as an argument:

The system responds with

The Service Management Facility (SMF) was described in Chapter 3, “Perform System Startup and Shutdown Procedures,” so I won’t be redundant by describing it again here. However, this is just a reminder that you can use the svcs command with the -p option to list all processes associated with each service instance.

When sitting at a terminal and typing in commands, the user is typically executing foreground processes. Commands such as vi are foreground processes—they read input from the keyboard and display output to the terminal. Foreground processes maintain control of the terminal, and the user cannot do anything else in that terminal window until the execution of that command is complete.

Some processes are not interactive and don’t need to run in the foreground. These are referred to as background processes or jobs. A background process gets detached from the terminal, freeing up the terminal while it is running. When a user decides to run a process in the background, you must arrange for the process to get its input from another source. In addition, you need to arrange for the process to output to a device other than the terminal, such as a file.

To run a process in the background, enter an & (ampersand) after the command:

After typing in this command, you’re returned to a command prompt. The find command executes in the background. One problem, however, is the standard output is still on your terminal. In other words, as the find command executes, the results still are displayed on your screen, which can become quite annoying. It’s best to redirect the output to a file, as follows:

After you put the find command in the background, the system displays two numbers associated with that process—the job number and the process ID number (PID) as follows:

You use this job number to control background processes.

Note

The shell maintains a table containing information about processes that are currently in the background. This is referred to as the jobs table. The jobs table is unique to the user, and each user has his own jobs table. Furthermore, the jobs table contains only entries for jobs that are running in your current shell. If you start a new shell, the jobs table for the new shell is empty. Each job in the table is assigned a number that is unique to that user only. In other words, two users can each have a job numbered 1. Don’t confuse this job number with a process ID number; remember, process IDs are unique, and no two share the same number. Any jobs that the user has placed in the background are displayed here by typing in the jobs command, as follows:

The system responds with this:

The jobs table contains the following information:

Each job in the job table has one of the following states:

When the job finishes, the following is displayed on your terminal:

Note the job number of 1 and the status of Done.

If you want to terminate a job, use the kill command followed by a % (percent sign) and then the job number, as follows:

Caution

If you do not enter a number following the % sign, the command acts upon the current job entry listed in the jobs table. For this example, you are going to kill job number 1, as follows:

The following message is displayed indicating successful termination:

You can also bring a job back into the foreground with the fg command. Typing fg with no arguments brings the current job (the job with the + sign next to it in the jobs table) into the foreground. You can also specify the job by typing fg %<job number>, as follows:

This brings job 2 back into the foreground on your terminal.

In a windowing environment such as Java Desktop System, placing jobs in the background is not an issue. Typically, you start a job in one window and open another window to continue working. Therefore, placing jobs into the background has all but disappeared unless you are working on a character-based terminal.

Objective:

Clearing hung processes.

Solaris supports the concept of sending software signals to a process. These signals are ways for other processes to interact with a running process outside the context of the hardware. The kill command is used to send a signal to a process. System administrators most often use the signals SIGHUP, SIGKILL, SIGSTOP, and SIGTERM. The SIGHUP signal is used by some utilities as a way to notify the process to do something, such as re-read its configuration file. The SIGHUP signal is also sent to a process if the remote connection is lost or hangs up. The SIGKILL signal is used to abort a process, and the SIGSTOP signal is used to pause a process. The SIGTERM signal is the default signal sent to processes by commands such as k ill and pkill when no signal is specified. Table 5.12 describes the most common signals an administrator is likely to use.

Exam Alert

In addition, you can write a signal handler, or trap, in a program to respond to a signal being sent. For example, many system programs, such as the name server daemon, respond to the SIGHUP signal by re-reading their configuration files. This signal can then be used to update the process while running, without having to terminate and restart the process. Signal handlers cannot be installed for SIGSTOP (23) or SIGKILL (9). Because the process cannot install a signal handler for signal 9, an otherwise well-behaved process may leave temporary files around or not be able to finish out critical operations that it is in the middle of. Thus, kill -9 invites corruption of application data files and should only be used as a last resort.

Here’s an example of how to trap a signal in a script:

As the name suggests, trap traps system interrupt until some command can be executed. The previous example traps the signals 1, 2, 3, and 15, and executes the /bin/rm tmp$$ command before exiting the program. The example deletes all tmp files even if the program terminates abnormally.

The kill command sends a terminate signal (signal 15) to the process, and the process is terminated. Signal 15, which is the default when no options are used with the kill command, is a gentle kill that allows a process to perform cleanup work before terminating. Signal 9, on the other hand, is called a sure, unconditional kill because it cannot be caught or ignored by a process. If the process is still around after a kill -9, either it is hung up in the Unix kernel, waiting for an event such as disk I/O to complete, or you are not the owner of the process.

The kill command is routinely used to send signals to a process. You can kill any process you own, and the superuser can kill all processes in the system except those that have process IDs 0, 1, 2, 3, and 4. The kill command is poorly named because not every signal sent by it is used to kill a process. This command gets its name from its most common use—terminating a process with the kill -15 signal.

Note

You can send a signal to a process you own with the kill command. Many signals are available, as listed in Table 5.12. To send a signal to a process, first use the ps command to find the process ID (PID) number. For example, type ps -ef to list all processes and find the PID of the process you want to terminate:

To kill the process with a PID number of 5497, type this:

Another way to kill a process is to use the pkill command. pkill functions identically to pgrep, which was described earlier, except that instead of displaying information about each process, the process is terminated. A signal name or number may be specified as the first command-line option to pkill. The value for the signal can be any value described in Table 5.12. For example, to kill the process named psef with a SIGKILL signal, issue the following command:

Note

In addition, the Desktop Process Manager, which was described earlier, can be used to kill processes. In the Process Manager window, highlight the process that you want to terminate, click Process from the toolbar at the top of the window, and then select Kill from the pull-down menu, as shown in Figure 5.9.

Figure 5.9 Killing processes.

The equivalent Unix command used by the Process Manager to terminate a process is shown here:

<PID> is the process ID of the selected process.

The preap command forces the killing of a defunct process, known as a zombie. In previous Solaris releases, zombie processes that could not be killed off remained until the next system reboot. Defunct processes do not normally impact system operation; however, they do consume a small amount of system memory. See the preap manual page for further details of this command.

Processes compete for execution time. Scheduling, one of the key elements in a time-sharing system, determines which of the processes executes next. Although hundreds of processes might be present on the system, only one actually uses a given CPU at any given time. Time sharing on a CPU involves suspending a process and then restarting it later. Because the suspension and resumption of active processes occurs many times each second, it appears to the user that the system is performing many tasks simultaneously.

Unix attempts to manage the priorities of processes by giving a higher priority to those that have used the least amount of CPU time. In addition, processes that are waiting on an event, such as a keyboard press, get higher priority than processes that are purely CPU-driven.

On any large system with a number of competing user groups, the task of managing resources falls to the system administrator. This task is both technical and political. As a system administrator, you must understand your company goals to manage this task successfully. When you understand the political implications of who should get priority, you are ready to manage the technical details. As root, you can change the priority of any process on the system by using the nice or priocntl commands. Before you do this, you must understand how priorities work.

All processes have assigned to them an execution priority—an integer value that is dynamically computed and updated on the basis of several different factors. Whenever the CPU is free, the scheduler selects the most favored process to resume executing. The process selected is the one with the lowest-priority number because lower numbers are defined as more favored than higher ones. Multiple processes at the same priority level are placed in the run queue for that priority level. Whenever the CPU is free, the scheduler starts the processes at the head of the lowest-numbered nonempty run queue. When the process at the top of a run queue stops executing, it goes to the end of the line and the next process moves up to the front. After a process begins to run, it continues to execute until it needs to wait for an I/O operation to complete, receives an interrupt signal, or exhausts the maximum execution time slice defined on that system. A typical time slice is 10 milliseconds.

A Unix process has two priority numbers associated with it. One of the priority numbers is its requested execution priority with respect to other processes. This value (its nice number) is set by the process’s owner and by root; it appears in the NI column in a ps -1 listing. The other priority assigned to a process is the execution priority. This priority is computed and updated dynamically by the operating system, taking into account such factors as the process’s nice number, how much CPU time it has had recently, and other processes that are running and their priorities. The execution priority value appears in the PRI column on a ps -1 listing.

Although the CPU is the most-watched resource on a system, it is not the only one. Memory use, disk use, I/O activity, and the number of processes all tie together in determining the computer’s throughput. For example, suppose you have two groups, A and B. Both groups require large amounts of memory—more than is available when both are running simultaneously. Raising the priority of Group A over Group B might not help if Group B does not fully relinquish the memory it is using. Although the paging system does this over time, the process of swapping a process out to disk can be intensive and can greatly reduce performance. A better alternative might be to completely stop Group B with a signal and then continue it later, when Group A has finished.

A way to divide processes on a busy system is to schedule jobs so that they run at different times. A large job, for example, could be scheduled to run at 2:00 a.m., when the system would normally be idle. Solaris supports two methods of batch processing: the crontab and at commands. The crontab command schedules multiple system events at regular intervals, and the at command schedules a single system event.

Objective:

Explain how to schedule an automatic one-time execution of a command.

The at command is used to schedule jobs for execution at a later time. Unlike crontab, which schedules a job to happen at regular intervals, a job submitted with at executes once, at the designated time.

To submit an at job, type at. Then specify an execution time and a program to run, as shown in the following example:

When you submit an at job, it is assigned a job identification number, which becomes its filename along with the .a extension. The file is stored in the /var/spool/cron/atjobs directory. In much the same way as it schedules crontab jobs, the cron daemon controls the scheduling of at files.

The command syntax for at is shown here:

The at command is described in Table 5.15.

You can set up a file to control access to the at command, permitting only specified users to create, remove, or display queue information about their at jobs. The file that controls access to at is /etc/cron.d/at.deny. It consists of a list of usernames, one per line. The users listed in this file cannot access at commands. The default at.deny file, created during the SunOS software installation, contains the following usernames:

With superuser privileges, you can edit this file to add other usernames whose at access you want to restrict.

The Solaris Management Console (SMC) includes a graphical tool to create and schedule jobs on your system. You can use the Job Scheduler Tool to

To open the Job Scheduler, follow the steps described in the “SMC Process Tool” section to start up the SMC using the smc command.

1.   In the Navigation pane of the SMC Welcome window, open the Job Scheduler by clicking on the This Computer icon, then click on the Services icon, and then click on the Scheduled Jobs icon as shown in Figure5.10.

Figure 5.10 Opening the Job Scheduler.

2.    You can add jobs to the crontab by selecting Action from the top toolbar as shown in Figure 5.11.

Figure 5.11 Adding a cron job.

3.   Modify a cron job by double clicking on the job in the main window pane as shown in Figure 5.12.

Figure 5.12 Modifiying a cron job.

This chapter described Solaris processes and the various Solaris utilities available to monitor them. Using commands such as ps, prstat, pargs, sdtprocess, and the SMC Process Tool, you can view all the attributes associated with a process. In addition, we described foreground and background jobs.

The concept of sending signals to a process was described. A signal is a message sent to a process to interrupt it and cause a response or action. You also learned how to send signals to processes to cause a response such as terminating a process.

Setting process priorities was described. We also described the concept of projects and tasks along with administrative commands used to administer them. The various commands, such as nice and priocntl, that are used to set and change process priorities were described. In addition, you learned how to use the crontab and at facilities. You can use these facilities to submit batch jobs and schedule processes to run when the system is less busy, to reduce the demand on resources such as the CPU and disks.

The system administrator needs to be aware of the processes that belong to each application. As users report problems, the system administrator can quickly locate the processes being used and look for irregularities. By keeping a close watch on system messages and processes, you’ll become familiar with what is normal and what is abnormal. Don’t wait for problems to happen—watch system messages and processes daily. Create shell scripts to watch processes for you and to look for irregularities in the system log files. By taking a proactive approach to system administration, you’ll find problems before they affect the users.

In Chapter 6, “Managing the LP Print Service,” we’ll explore another topic that you’ll need to become acquainted with—the LP Print Service, the facility responsible for printing within the Solaris environment.

1.   Calkins, Bill. Inside Solaris 9. New Riders Publishing. November 2002.