Module 5

UNIX Process
2
Process Basics
A process is simply an instance of a running program. It is said to be born when the program starts
execution and remains alive as long as the program is active. After execution is complete, the process
is said to die.

A process also has a name, usually the name of the program being executed. For example, when you
execute the grep command, a process named grep is created.

Most UNIX commands that we execute actually run as processes; very few don’t. A few commands,
like shell built-ins (cd, echo), don't create separate processes—they execute directly within the shell.

3
Process Basics(cont’d)
• Even though a process originates from a program, a process can’t be considered synonymous
with a program.

• There are a number of ways that the two can differ. First, when two users run the same
program, there’s one program on disk but two processes in memory.

• Second, when you execute a shell script (also a program) containing a pipeline of three
commands, you have three processes.

• The shell serves the user, but the kernel handles processes.

• The kernel manages memory and schedules processes so that each process has a fair share of
the CPU and other resources.

4
Process Basics(cont’d)
• It provides a mechanism by which a process is able to execute for a finite period of time and
then relinquish control to another process.

• The kernel has to save the state of the current process (like the instruction it was currently
executing) so that when its turn comes up again for execution, the kernel knows where to
resume.

• All of this happens more than once a second, making the user oblivious to the switching
process.

5
Process Basics(cont’d)
• Files have attributes and so do processes.
• Most process attributes are stored in the process table, a separate structure maintained in
memory by the kernel.
• You could say that the process table is the inode for processes.
• A process retains an entry in this table until it dies “properly.” Because the table is of finite
size, there is a limit to the maximum number of processes that can run on a system.

6
Process Basics(cont’d)
• Most process attributes are inherited by the child from its parent, and some of the attributes
are allocated by the kernel when a process is born.

• The two important attributes of a process are

•The Process-id
PID (PID)

•The Parent PID

PPID
(PPID)
7
Process Basics(cont’d)
The Process-id (PID) Each process is
identified by a unique integer called the
Process-id (PID). We need the PID to control
(PID) a process, for instance, to kill it. The first
process has the PID 0.

The Parent PID (PPID) The PID of the parent

is also available in the processtable. When
several processes have the same PPID, it
(PPID) often makes sense to kill the parent rather
than all of its children separately.

8
 The Shell Process
• When you log in, the process representing the shell starts running at your terminal. This process
may be sh, ksh, csh, or bash.
• The shell maintains a set of environment variables, and you have already encountered some of
them like PATH and HOME.
• The shell’s own pathname is stored in SHELL, but its PID is stored in a special “variable”, $$.
• To know the PID of your current shell,

$ echo $$ The PID of the current shell

• The PID of your login shell obviously can’t change as long as you are logged in.
• When you log out and log in again, your login shell will be assigned a different PID.
• Knowledge of the PID is often necessary to control the activities at your terminal, especially when
things go wrong.

9
 The Shell Process (cont’d)

• The PPID of every login shell is always 1.

• This is the init process: the second process of the system.

• init is a very important process and, apart from being the parent of users’ shells, it is also
responsible for giving birth to every service that’s running in the system—like printing, mail, Web,
and so on.

10
Parents and Children
Every process has a parent. This parent itself is another process, and a process born from it
is called its child.

When you run the command

cat [Link]

from the keyboard a process representing the cat command is started by the shell process.

The shell (sh,ksh,bash) is said to be parent of cat , while cat is the child of the shell.

The ancestry of every process is ultimately traced to the first process (PID0) that is set up
when the system is booted

11
Wait or Not Wait?
The two different behavior of the parent towards its child:

• It may wait for the child to die so that it can spawn(generate) the next process. The
death is informed by the kernel to the parent. When you execute the command from the
shell, the shell process waits for the command to die before it returns the prompt to take
up the next command.

• It may not wait for the child to die at all and may continue to spawn other processes.
This is what the init process does(init is the parent of several processes).

12
 ps: Process Status
The ps (process status) command to display some process attributes. ps fetches these attributes from
the process table.

Compare this to ls, which looks up the inode to retrieve a file’s attributes.

By default, ps displays the processes owned by the user invoking the command:

$ps
PID TTY TIME CMD
1078 pts/4 0:00 bash The login shell of this user

Here the login shell is bash (CMD) and has the PID 1078, the same number echoed by the special
variable, $$.
It is running at the terminal /dev/pts/4 (TTY).
The cumulative processor time (TIME) that has been consumed since the process started is negligible.
That is to be expected because the shell is mostly sleeping—waiting 13
 ps Options
ps presents a snapshot of the process table. On some systems, you might see ps itself in the output.

ps is a highly variant command; its actual output varies across different UNIX flavors

14
Displaying the PPID (-f) – Full listing
• Since knowing the parentage is often important, the –f option displays a fuller listing that
includes the PPID. To get a detailed listing which also shows the parent of every process,
use -f option
$ ps -f
UID PID PPID C STIME TTY TIME CMD
sumit 1081 1078 0 [Link] pts/4 0:00 vi create_user.sh
sumit 1082 1081 0 [Link] pts/4 0:00 /usr/bin/bash -i
sumit 1078 1 0 [Link] pts/4 0:00 bash

Apart from the vi editor, there are two shells running here, and the -f option easily identifies a
login shell by the hyphen preceding the command name.
Note that init is the parent of the login shell (PID 1078, PPID 1).
Here, we have an unusual hierarchy. The vi process is the child of the login shell, and the
second shell is the child of vi.
15
Displaying Processes of a user(-u)
• To know the activities of any user, the –u option can be used.

$ps –u sumit
PID TTY TIME CMD
4321 pts/1 [Link] bash
5678 pts/1 [Link] sshd
9101 pts/1 [Link] python3
1145 pts/1 [Link] top

16
Display all user processes(-a)
• The -a option lists processes of all users but does not display the system processes.

$ps -a
PID TTY TIME CMD
662 pts/01 [Link] ksh
705 pts/04 [Link] sh
680 pts/05 [Link] sort
1056 pts/08 [Link] ps

17
 Displays system Processes(-e or A)
• Even though no one may be using the system, a number of system processes keep running all
the time. They are spawned during system startup by init (PID 1), the parent of the login shell.

• The ps -e or ps –A
command lists them all.

18
 Displays system Processes(-e or A)
• System processes that have no controlling terminal are easily identified by the ? in the TTY
column. A process that is disassociated from the terminal can neither write to the terminal nor
read from it. You can’t press [Ctrl-c] to interrupt the process either.

• Such processes are also known as daemons. A daemon process is a background process that
runs independently of user control. These processes are typically started at system boot and run
continuously, providing various essential services.

• Many of these daemons are actually sleeping (a process state) and wake up only when they
receive input.

• Daemons do important work for the system. The lpsched daemon controls all printing activity.
sendmail handles both your incoming and outgoing mail. Your TCP/IP network won’t run FTP
and TELNET without the inetd daemon. cron looks at its control file once a minute to decide
what it should do.

19
Mechanism of Process Creation:

exec
k wa
r it
fo

20
 Mechanism of Process Creation:
• There are three distinct phases in the creation of process and uses three important system
calls or functions with the same name.

• They are fork, exec and wait.

Fork Forking creates a process by creating a copy of the existing process. The new process has a
different PID, and the process that created it becomes its parent.
Otherwise, parent and child have the same process image.
If the child doesn’t do an exec, both parent and child continue to execute the same code from the point
forking was invoked.

21
Mechanism of Process Creation(Cont’d)
Exec Forking creates a process, but it is not enough to run a new program. To do that, the forked
child needs to overwrite its own image with the code and data of the new program.
This mechanism is called exec, and the child process is said to exec a new program.
No new process is created here; the PID and PPID of the exec’d process remain unchanged.

Wait While the child is executing a new program, the parent normally waits for the child to die.
It then picks up the exit status of the child before it does something else.

22
23
Mechanism of Process Creation: Inherited Process Attributes
• When a process is forked and exec’d, the new program has a different PID and PPID than its
parent. However, it inherits most of the environment of its parent.
• The important attributes that are inherited are:

• The real UID and real GID of the process. These represent the user ID and group ID of the
user running the process and are stored in /etc/passwd.

• The effective UID and effective GID of the process. These are generally the same as their
“real” cousins, but some processes behave differently when used with setuid program, thereby
altering the access permissions. It determines the access permissions for the process.
• Unlike the Real User ID (RUID), which represents the actual user who started the process,
Effective UID (EUID) is used for access control and is typically the owner of the program
being executed.

24
Mechanism of Process Creation: Inherited Process Attributes
• The current directory from where the process was run. You must remember this to
understand why you can’t create a process to change your current directory.

• The descriptors of all files opened by the parent process. Recall that these are small integers
that are used to identify opened files. Note that normally the kernel reserves the first three
slots (0, 1, and 2) in the file descriptor table for the shell’s standard streams.

• Environment variables (like HOME and PATH). Every process knows the user’s home
directory and the path used by the shell to look for commands.

25
How the shell is created

• Process Creation and Shell Initialization: Creating a shell involves a series of process
creations and executions

26
How the shell is created(cont’d)
• Boot and Init: The system boots, and the initial process (init or systemd in many modern
systems) starts up.
• Multi-User Mode: The system transitions to multi-user mode. init forks and execs a getty
process for each active terminal.
• Login Prompt: getty displays the login prompt and waits for user input.
• User Login:
• User Enters Credentials: The user provides their login name and password.
• Verify Credentials: getty wakes up, forks, and execs the login program, which verifies the
credentials.
• Starting the Shell:
• Successful Login: If login is successful, the login program forks and execs the shell
specified for the user (like /bin/bash or /bin/sh).
• Shell Initialization: The shell initializes, sets up the environment, and begins executing user
commands interactively.

27
How the shell is created(cont’d)
• Through these layers of forking and execing, each step ensures that init is the grandparent (or
ancestor) of all user processes.

• Once the shell is running, init sleeps but continues monitoring its child processes, ready to take
action if any child process terminates.

• When a user logs out, the shell process terminates. This termination is communicated to init,
which is always monitoring its child processes.

• init then springs back to action, spawning a new getty process to handle the next login attempt.
This ensures that the system is always ready to welcome new users seamlessly.

• The way these processes hand off to one another keeps the system running smoothly and
efficiently, maintaining a ready state for multi-user access
28
Three types of commands
The shell recognizes three types of commands.

External commands: The shell creates a process for each of these commands that it executes
while remaining their parent. Ex: cat,ls

Internal commands: The shell has a number of built in commands. Ex: For the commands like
cd and echo the shell doesn’t generate a process and are executed directly by the shell.

Shell scripts: The shell executes these scripts by spawning another shell which then executes the
command listed in the script. The child shell becomes the parent of the commands that features in
the script.

29
Why directory change cant be made in separate process?

• When you attempt to change the current directory within a separate process, the change is
isolated to that process and doesn't affect the parent process. This is due to the way environment
variables, including the current working directory, are inherited by child processes.

• When a new process is spawned, it operates within its own context. Any changes it
makes—like changing the directory with cd—affect only that process and its children, not the
parent process from which it was launched. This isolation ensures that each process remains
unaffected by the directory changes made by others.

• It's like each process operates within its own little bubble, carrying a snapshot of the
environment it inherited, including the working directory. This isolation is part of what makes
process management in UNIX so robust and predictable.

30
Process States and Zombies
• Here are the key process states: At any instant of time, a process is in a particular state.

• Running: The process is actively executing on the CPU.

• Waiting (Blocked/Sleeping): The process is waiting for an event or resource (like I/O
operation completion).

• Stopped: The process has been stopped, typically by receiving a signal.

• Zombie: The process has completed execution, but its parent hasn't yet read its exit status. It
remains in the process table as a "zombie."

31
Process States and Zombies
• A zombie state occurs when a process has completed execution but still has an entry in the
process table.

• This happens because the process's parent hasn't yet read its exit status, often done using the
wait system call.

• While the zombie process isn't using system resources like CPU or memory, it does occupy a
process table slot.

• A zombie is a harmless dead child and You can't kill a zombie because it's already
terminated; it's waiting for its parent to acknowledge its death.

• The parent may also die before the child dies. The child then becomes an orphan and the
kernel makes init the parent of all orphans.
• In essence, zombies are waiting for cleanup by their parents, while orphans are adopted by
init to keep running.
32
Zombie Process: Orphan Process:

• Definition: A process that has completed • Definition: A process whose parent has
execution but still has an entry in the process terminated or died.
table.
• Reason: The parent process terminates before
• Reason: This occurs because its parent has not the child, leaving it "orphaned."
yet read its exit status using the wait system
call. • Reassignment: The kernel reassigns the
orphaned process to init (or systemd), ensuring
• Status: The process is "dead" and uses no it has a new parent to adopt and manage it.
system resources but remains in the process
table until its parent cleans it up. • Status: Orphans continue running normally
under the new parent process.

33
 at and batch: Execute Later
• UNIX provides sophisticated facilities to schedule a job to run at a specified time of day.
• If the system load varies greatly throughout the day, it makes sense to schedule less urgent jobs at a
time when the system overheads are low.
• The at and batch commands make such scheduling possible.

at: One-Time Execution

• at schedules jobs for one-time execution. The command runs with the scheduled date and time as
arguments. The command to run is specified at the at> prompt:

34
at and batch: Execute Later(cont’d)
$ at 14:08
at> [Link]
[Ctrl-d]
commands will be executed using /usr/bin/bash
job 1041188880.a at Sun Dec 29 [Link] 2002

• The jobs are submitted to a queue. The job-id is derived from the number of seconds since the
Epoch.
• At 2:08 p.m. today, the program [Link] will be executed.

• Unless redirected, the standard output and error will be mailed to the user. Alternatively, you may
provide redirection at the at> prompt itself:
at 15:08
[Link] > [Link]
35
at and batch: Execute Later(cont’d)
at also offers keywords like now, noon, today, and tomorrow. It also offers the words hours, days,
weeks, and so forth to be used with the + symbol.

The following forms show the use of some of the key words and operators:

at 15 24-hour format assumed

at 3:08pm
at noon At 12:00 hours today
at now + 1 year At the current time after one year
at 3:08pm + 1 day At 3:08 p.m. tomorrow
at 15:08 December 18, 2001
at 9am tomorrow

You can also use the -f option to take commands from a file.
36
 batch: Execute in Batch Queue
• The batch command in UNIX is used to schedule commands to run when the system load is low.
• It works similarly to the at command but is particularly useful for background tasks that can run
whenever the system isn't busy.

• The command doesn’t take any arguments but uses an internal algorithm to determine the execution
time. This prevents too many CPU-hungry jobs from running at the same time.

• The response of batch is similar to at otherwise:

$ batch < [Link]
commands will be executed using /usr/bin/bash
job 1041185673.b at Sun Dec 29 [Link] 2002

• Any job scheduled with batch goes to a special at queue, and it can also be removed with at -r
37
 cron and crontab: Running Jobs Periodically
• The ps -e command always shows the cron daemon running. This is the UNIX system’s
chronograph, ticking away every minute.

• The cron command is used to schedule repetitive tasks to run at specified intervals. This is managed
through the cron daemon, which runs in the background and executes tasks defined in crontab
files.

• cron is not a one-time scheduler like at but a periodic one. Every minute it wakes up from its
sleeping state to look up a crontab file for instructions to be performed at that instant.

• After executing them, it goes back to sleep, only to wake up the next minute.

38
 cron and crontab: Running Jobs Periodically(cont’d)
• The crontab file is named after the user-id and is typically located in /var/spool/cron/crontabs.
• This location is, however, system-dependent. Every scheduled job is specified as a single line in this
file as given below:

39
 cron and crontab: Running Jobs Periodically(cont’d)
• There are six fields in the line, and the first five completely determine how often the command will
be executed. The following list shows the significance of the fields with their permissible values
shown in parentheses:

1 The minute (00 to 59)

2 The hour (0 to 23)
3 The day (0 to maximum number of days in month)
4 The month (1 to 12)
5 The day of the week (0 to 6, 0 being a Sunday)
6 Command to run

• This find command runs at 18:15 hours on June 30 every year. We didn’t make use of the fifth field
(which doesn’t have much relevance here) and preferred to place a * there. As with at, in the
absence of redirection, the standard output of the command is mailed to the user.
40
 cron and crontab: Running Jobs Periodically(cont’d)
• To create a crontab entry, first use your vi editor to create a file foo with an entry of your choice.
Then use the crontab command
crontab foo
• to place the entry in the directory /var/spool/cron/crontabs. You can see the contents of your crontab
file with crontab -l and remove it with crontab -r.

41
 cron and crontab: Running Jobs Periodically(cont’d)
• cron’s strength lies in its unusual number matching system.
• For instance, this entry:
00-10 17 * 3,6,9,12 5 find / -newer .last_time -print > backuplist
• The first two fields indicate that the command is to run every minute from 17:00 hours to 17:10
hours.
• The third field (being a *) specifies that it should run every day.
• The fourth field (3,6,9,12), however, restricts the operation to four months of the year.
• The fifth field limits execution to every Friday.

42
 cron and crontab: Running Jobs Periodically(cont’d)
• cron is mainly used by the system administrator to perform housekeeping chores, like removing
outdated files or collecting data on system performance.
• It’s also extremely useful to periodically dial up to an Internet mail server to send and retrieve mail.

Controlling Access to cron

• Not all users may be able to use cron.
• As with at and batch, the authorization to use it is controlled by two files, [Link] and [Link].
• If [Link] is present, only users included in this file are allowed to use this facility.
• If this file is not present, [Link] is checked to determine the users who are prohibited.
• In case neither of them is present, depending on the system configuration, either the system
administrator only is authorized to use cron or all users are allowed access.

43
 nice command: Job Execution with low priority
• Processes in UNIX system are usually executed with equal priority. This is not always desirable,
since high priority jobs has to be executed first.
• UNIX offers the nice command which is used with & operator to reduce the priority of jobs. The
nice command in UNIX and Linux is used to set the priority of a process.
• It allows you to influence how much CPU time a process gets compared to others. To run a job with
low priority the command name should be prefixed with nice.

nice wc -l uxmanual default niceness value of 10

• nice is a shell built in command and its value are system dependent and typically range from 1 to 19.

44
 nice command: Job Execution with low priority(cont’d)
• A higher nice value implies low priority. nice reduces the priority of any process and thereby raising
the nice value.
• We can also specify the nice value explicitly with -n option
nice -n 5 wc -l uxmanual & niceness value of 5

• nice -n 5: Sets the niceness value to 5, giving it a slightly lower priority compared to default
priority (0).

• wc -l uxmanual: Counts the lines in the uxmanual file.

• &: Runs the command in the background, allowing the terminal to be free for other tasks.

45
 Running jobs in background
• UNIX is a multitasking system that allows a user to run more than one job at a time.
• This feature works in all shells, allowing us to relegate time-consuming or low priority jobs to the
background and to run an important one in the foreground.
• There are two ways of running jobs in the background—with the shell’s & operator and the
nohup command.

46
Running jobs in background(cont’d)
&: No Logging Out
• The & is the shell’s operator used to run a process in the background. The parent in this case doesn’t
wait for the child’s death. Just terminate the command line with an &; the command will run in the
background:
$ sort -o [Link] [Link] &
550 The job’s PID
$_ Shell doesn’t wait; prompt returns

• The shell immediately returns the PID of the invoked command (550) and then the prompt. This
means that the shell doesn’t wait for the death of sort (though it will eventually pick up its exit
status).
• You can now enter your next command, and using an & with each, you can run as many jobs in the
background as the system load permits.
• For most shells, the system variable $! stores the PID of the last background job. So you can
kill the last background process using kill $!
47
Running jobs in background(cont’d)
• nohup: Log Out Safely
• When a command is run with nohup (no hangup), the process continues to run even after the user
has logged out.
• This feature is not required in the Bash and C shells because background processes in these shells
continue to run even after the user has logged out, but it is required for the Bourne and Korn shells.
• You must use the & with it as well:

$ nohup sort [Link] &

586 PID of this job
Sending output to [Link]

• Some shells display this message. In the absence of redirection, nohup sends the standard output of
the job to [Link]. You can now safely log out of the system without aborting the command.

48
Running jobs in background(cont’d)
• Background processes cease to run when the user logs out. This is because the shell(parent process)
is killed. The nohup command permits execution of the process even after the user has logged out.
• When the user logs out, init process becomes the parent process for the background process.

49
Running jobs in background(cont’d)
• If you are running the command from a window, then close the window. Log in again or run ps from
another window or terminal to notice something quite significant:
$ ps –f –u sumit
UID PID PPID C STIME TTY TIME COMMAND
sumit 586 1 45 [Link] 01 0:13 sort [Link]

• The shell died on logging out but its child (sort) didn’t; it turned into an orphan. As discussed
previously, all orphans are adopted by init, and this is what has happened here.

• Unlike the &, which needs to be affixed only to the end of the command line, nohup needs to be
used with each command in a pipeline:
nohup grep ‘director’ [Link] & | nohup sort &

50
Job control
• Job control enables you to move jobs between foreground and background, suspend,
continue, and kill them.
• A job is identified by its job-id, which is different from the PID, the process identifier.
However, a job can also be identified by other means, and job control commands can be
used both with job-ids and other job identifiers as arguments
• A job is the name given to group of processes. Following are the list of job control
commands:
• Moves a job to background(bg)
• Bring it back to foreground(fg)
• List the active jobs(jobs)
• Suspend a foreground job([ctrl-z])
• kill a job(kill)

51
Job control(cont’d)
• let’s run this find command and then use the job control commands for manipulating it.
We’ll initially run find in the background with standard output and standard error redirected
suitably:
$ find / -name [Link] -print > files_to_remove 2>/dev/null &
[1] 1287 Shows both job-id and PID

Note that both job number and PID are displayed; this shell supports job control. Subsequent
job control commands can now access this job as %1.
You can now use the fg command to bring this job to the foreground:
$ fg %1
find / -name [Link] -print > files_to_remove 2>/dev/null

52
Job control(cont’d)
You can now use the fg command to bring this job to the foreground:
$ fg %1
find / -name [Link] -print > files_to_remove 2>/dev/null

You can now suspend this foreground job by pressing [Ctrl-z]:

[Ctrl-z]
[1]+ Stopped find / -name [Link] -print >files_to_remove 2>/dev/null

Observe that the job has not been terminated yet; it’s only suspended (“stopped”). You can
now use the bg command to push this suspended job to the background:
$ bg %1
[1]+ find / -name [Link] -print >files_to_remove 2>/dev/null &

53
Job control(cont’d)
• The job starts running once again. Before we run the jobs command, let’s run a few more
jobs in the background:
$ ls -lR / > system_list 2>/dev/list &
[2] 1288
$ du -s /users1/* > disk_usage &
[3] 1289

• The jobs command lists all jobs that are either running or suspended. The output shows that
none of the three commands has completed execution:
$ jobs
[1] Running find / -name [Link] -print >files_to_remove 2>/dev/null &
[2]- Running ls -lR / >system_list 2>/dev/list &
[3]+ Running du -s /users1/* >disk_usage &
54
Job control(cont’d)
• kill: Premature termination of a process:
• The kill command sends a signal usually with the intention of killing one or more processes. kill
is an internal command in most shells; the external /bin/kill is executed only when the shell lacks
the kill capability. The command uses one or more PIDs as its arguments, and by default uses the
SIGTERM (15) signal.
• you can kill a job with the shell’s built-in kill command. You can also use a job number with
kill:
$ kill %3
[3]+ Terminated du -s /users1/* >disk_usage
kill 105 to terminate the job with pid 105
kill 121 123 125 132 to terminate the jobs with all these pid
$sort -o [Link] [Link] & runs in background with PID 345
$ kill $! Killing the last background job with process id 345
$kill –l Gives a list of all signal names

55
Job control(cont’d)
• Using kill with Other Signals By default, kill uses the SIGTERM signal to terminate the
process.
• You may have noticed that some programs simply ignore this signal and continue execution
normally. In that case, the process can be killed with the SIGKILL signal (9).
• This signal can’t be generated at the press of a key, so you must use kill with the signal name
(without the SIG):
kill -s KILL 121 Recommended way of using kill
kill -9 121 Same as above but not recommended
• A simple kill command (with TERM) won’t kill the login shell. You can kill your login shell by
using any of these commands:
kill -9 $$ $$ stores PID of current shell
kill -s KILL 0 Kills all processes, including the login shell

56
Job control(cont’d)

• Apart from using job_ids, we can also access a job by a string that represents either the
command name or an embedded string in the command line.
• These are the three ways you identify a job to the system:
• %n Job number n
• %stg Job name that begins with stg
• %?stg Job name that contains an embedded stg

57
Time: timing processes
The time command in Unix and Linux is used to measure the duration of execution of a
command. It provides detailed timing information including real time, user CPU time, and system
CPU time.

For ex: to measure the time it takes to list all files in a large directory using ls:

$ time ls -l /path/to/large/directory

The output of the time command typically looks like this:

real 0m0.012s
user 0m0.003s
sys 0m0.009s
real: The total elapsed time (wall clock time) from start to finish of the command.
user: The amount of CPU time spent in user-mode (i.e., outside the kernel) within the process.
sys: The amount of CPU time spent in the kernel within the process. 58
Summary
• A process is an instance of a running program. It is identified by the process-id (PID) and its parent PID
(PPID). Process attributes are maintained in the process table in memory.
• Because of multitasking, a process can spawn multiple processes. The login shell is a process (PID = $$)
that keeps running as long as the user is logged in.
• You can list your own processes with ps, view the process ancestry (-f), all users’ processes (-a), and all
system processes (-e).
• System processes, often called daemons, are generally not attached to a terminal and are not invoked
specifically by a user. init is the parent of most daemons and all users’ shells.
• A process is created by forking, which creates a copy (a child) of itself. The child then uses exec to
overwrite itself with the image of the program to be run.
• The child turns into a zombie on termination. The kernel doesn’t remove its process table entry until the
parent picks up the exit status of the child.
• Premature death of the parent turns the child into an orphan, and init takes over the parentage of all
orphans.
• The child’s environment inherits some parameters from the parent, like the real and effective UID and GID,
the file descriptors, the current directory, and environment variables. However, changes in the child are not
made available in the parent.

59
Summary
• Built-in shell commands like pwd and cd don’t fork a separate process. Shell scripts use a sub-shell
to run the commands in a script.
• The UNIX kernel communicates with a process by sending it a signal. Signals can be generated from
the keyboard or by the kill command. You can kill a process with kill, and use kill -s KILL if a simple
kill doesn’t do the job.
• A job can be run in the background. nohup ensures that a background job remains alive even after the
user has logged out.
• The C shell, Korn and Bash shells enable job control. You can move jobs between foreground and
background (fg and bg) and suspend ([Ctrl-z]) them. You can list jobs (jobs) and also kill them (kill).
• You can schedule a job for one-time execution with at, or run it when the system load permits with
batch. cron lets you schedule jobs so that they run repeatedly. It takes input from a user’s crontab file
where the schedule and frequency of execution is specified by five fields using a special number
matching system.

60
End of Module 5

61
#include <stdio.h> else if (pid == 0) {
#include <stdlib.h> // Child process
#include <unistd.h> printf("Child Process: PID = %d\n", getpid());
printf("Child Process: Executing `date` command\n");
#include <sys/wait.h>
execl("/bin/ls", "ls", "-l", (char *)NULL);
// If execl fails
int main() {
perror("execl failed");
pid_t pid;
exit(EXIT_FAILURE);
int status; } else {
// Parent process
// Fork a new process printf("Parent Process: PID = %d, waiting for child to
pid = fork(); complete...\n", getpid());
waitpid(pid, &status, 0);
if (pid < 0) {
// Fork failed if (WIFEXITED(status)) {
perror("fork failed"); printf("Parent Process: Child exited with status %d\n",
exit(EXIT_FAILURE); WEXITSTATUS(status));
} else {
}
printf("Parent Process: Child terminated abnormally\n");
}
} return 0; 62
}
Fork:
∙ pid = fork();: Creates a new child process.
∙ The fork function returns:
o -1 if the fork fails.
o 0 to the child process.
o The child's PID to the parent process.
 Child Process:
∙ execl("/bin/date", "date", (char *)NULL);: Replaces the child's memory space with a
new program (date command).
∙ If execl fails, it prints an error message and exits.
 Parent Process:
∙ waitpid(pid, &status, 0);: Waits for the child process to terminate.
∙ Checks the termination status of the child process:
o WIFEXITED(status): If the child terminated normally, prints the exit status.
o Otherwise, prints that the child terminated abnormally.

63
64