Unix / Linux – Processes

Unix-Linux - Processes-Management

Unix / Linux – Processes Management

In this part, we will examine in insight regarding process management in Unix. At the point when you execute a program on your Unix framework, the framework establishes a unique climate for that program. This climate contains everything required for the framework to run the program as though no other program were running on the framework.

At whatever point you issue an order in Unix, it makes, or starts, another process. At the point when you evaluated the ls order to list the catalog substance, you began a process. A process, in basic terms, is an occurrence of a running system.

The working framework tracks processes through a five-digit ID number known as the pid or the process ID. Each process in the framework has a special pid.

Pids at last rehash since all the potential numbers are spent and the following pid rolls or begins once again. Anytime of time, no two processes with a similar pid exist in the framework since the pid Unix uses to follow each process.

Starting a Process

When you start a process (run a command), there are two ways you can run it −

  • Foreground Processes
  • Background Processes

Foreground Processes

By default, every process that you start runs in the foreground. It gets its input from the keyboard and sends its output to the screen.

You can see this happen with the ls command. If you wish to list all the files in your current directory, you can use the following command −

$ls ch*.doc

This would display all the files, the names of which start with ch and end with .doc −

ch01-1.doc   ch010.doc  ch02.doc    ch03-2.doc 
ch04-1.doc   ch040.doc  ch05.doc    ch06-2.doc
ch01-2.doc   ch02-1.doc

The process runs in the foreground, the output is directed to my screen, and if the ls command wants any input (which it does not), it waits for it from the keyboard.

While a program is running in the foreground and is time-consuming, no other commands can be run (start any other processes) because the prompt would not be available until the program finishes processing and comes out.

Background Processes

A background process runs without being connected to your keyboard. If the background process requires any keyboard input, it waits.

The advantage of running a process in the background is that you can run other commands; you do not have to wait until it completes to start another!

The simplest way to start a background process is to add an ampersand (&) at the end of the command.

$ls ch*.doc &

This displays all those files the names of which start with ch and end with .doc −

ch01-1.doc   ch010.doc  ch02.doc    ch03-2.doc 
ch04-1.doc   ch040.doc  ch05.doc    ch06-2.doc
ch01-2.doc   ch02-1.doc

Here, if the ls command wants any input (which it does not), it goes into a stop state until we move it into the foreground and give it the data from the keyboard.

That first line contains information about the background process – the job number and the process ID. You need to know the job number to manipulate it between the background and the foreground.

Press the Enter key and you will see the following −

[1]   +   Done                 ls ch*.doc &
$

The first line tells you that the ls command background process finishes successfully. The second is a prompt for another command.

Listing Running Processes

It is easy to see your own processes by running the ps (process status) command as follows −

$ps
PID       TTY      TIME        CMD
18358     ttyp3    00:00:00    sh
18361     ttyp3    00:01:31    abiword
18789     ttyp3    00:00:00    ps

One of the most commonly used flags for ps is the -f ( f for full) option, which provides more information as shown in the following example −

$ps -f
UID      PID  PPID C STIME    TTY   TIME CMD
amrood   6738 3662 0 10:23:03 pts/6 0:00 first_one
amrood   6739 3662 0 10:22:54 pts/6 0:00 second_one
amrood   3662 3657 0 08:10:53 pts/6 0:00 -ksh
amrood   6892 3662 4 10:51:50 pts/6 0:00 ps -f

Here is the description of all the fields displayed by ps -f command −

Sr.No.Column & Description
1UID

User ID that this process belongs to (the person running it)

2PID

Process ID

3PPID

Parent process ID (the ID of the process that started it)

4C

CPU utilization of process

5STIME

Process start time

6TTY

Terminal type associated with the process

7TIME

CPU time taken by the process

8CMD

The command that started this process

There are other options which can be used along with ps command −

Sr.No.Option & Description
1-a

Shows information about all users

2-x

Shows information about processes without terminals

3-u

Shows additional information like -f option

4-e

Displays extended information

Stopping Processes

Ending a process can be done in several different ways. Often, from a console-based command, sending a CTRL + C keystroke (the default interrupt character) will exit the command. This works when the process is running in the foreground mode.

If a process is running in the background, you should get its Job ID using the ps command. After that, you can use the kill command to kill the process as follows −

$ps -f
UID      PID  PPID C STIME    TTY   TIME CMD
amrood   6738 3662 0 10:23:03 pts/6 0:00 first_one
amrood   6739 3662 0 10:22:54 pts/6 0:00 second_one
amrood   3662 3657 0 08:10:53 pts/6 0:00 -ksh
amrood   6892 3662 4 10:51:50 pts/6 0:00 ps -f
$kill 6738
Terminated

Here, the kill command terminates the first_one process. If a process ignores a regular kill command, you can use kill -9 followed by the process ID as follows −

$kill -9 6738
Terminated

Parent and Child Processes

Each unix process has two ID numbers assigned to it: The Process ID (pid) and the Parent process ID (ppid). Each user process in the system has a parent process.

Most of the commands that you run have the shell as their parent. Check the ps -f example where this command listed both the process ID and the parent process ID.

Zombie and Orphan Processes

Ordinarily, when a kid process is murdered, the parent process is refreshed by means of a SIGCHLD signal. At that point the parent can do some other assignment or restart another youngster on a case by case basis. Nonetheless, at times the parent process is killed before its youngster is killed. For this situation, the “parent, all things considered,” the init process, turns into the new PPID (parent process ID). At times, these processes are called vagrant processes.

At the point when a process is murdered, a ps posting may in any case show the process with a Z state. This is a zombie or old process. The process is dead and not being utilized. These processes are unique in relation to the vagrant processes. They have finished execution yet at the same time discover a section in the process table.

Daemon Processes

Daemons are system-related background processes that often run with the permissions of root and services requests from other processes.

A daemon has no controlling terminal. It cannot open /dev/tty. If you do a “ps -ef” and look at the tty field, all daemons will have a ? for the tty.

To be precise, a daemon is a process that runs in the background, usually waiting for something to happen that it is capable of working with. For example, a printer daemon waiting for print commands.

If you have a program that calls for lengthy processing, then it’s worth to make it a daemon and run it in the background.

The top Command

The top command is a very useful tool for quickly showing processes sorted by various criteria.

It is an interactive diagnostic tool that updates frequently and shows information about physical and virtual memory, CPU usage, load averages, and your busy processes.

Here is the simple syntax to run top command and to see the statistics of CPU utilization by different processes −

$top

Job ID Versus Process ID

Background and suspended processes are usually manipulated via job number (job ID). This number is different from the process ID and is used because it is shorter.

In addition, a job can consist of multiple processes running in a series or at the same time, in parallel. Using the job ID is easier than tracking individual processes.