CPS 310 Unix Process Model

Total Page:16

File Type:pdf, Size:1020Kb

CPS 310 Unix Process Model D u k e S y s t e m s CPS 310 Unix Process Model Jeff Chase Duke University hp://www.cs.duke.edu/~chase/cps310 Operating Systems: The Classical View Programs Each process run as data data has a private independent virtual address processes. space and one or more threads. Protected ...and upcalls system calls (e.g., signals) Protected OS Threads kernel enter the mediates kernel for access to OS shared services. resources. The kernel code and data are protected from untrusted processes. Today • We understand threads and concurrency now. • Add a kernel and address spaces à “vanilla Unix” • Flesh out Unix process model and syscall API • Kernel interactions • Using the process model • Imagine: – Your thread library is “really” a kernel. – Each thread is a classical process. – i.e., Each thread has its own VAS. – i.e., Threads/processes share data only within/via the kernel. Thread states and transitions We will presume that these transitions occur only in kernel mode. This is true in classical Unix and in systems with pure kernel-based threads. Before a thread can sleep, it Before a thread can yield, it must enter must first enter the kernel via the kernel, or the core must take an trap (syscall) or fault. interrupt to return control to the kernel. running On entry to the running yield state, kernel code decides preempt if/when/how to enter user sleep mode, and sets up a dispatch suitable context wakeup E.g., for initial start, return blocked ready from fault or syscall, or to deliver a signal. STOP wait Kernel Stacks and Trap/Fault Handling System calls and Threads execute data faults run in kernel user code on a user mode on a kernel stack in user space stack for the (the process virtual stack stack current thread. address space). Each thread has a Kernel code second kernel stack syscall running in P’s in kernel space (VM dispatch process context accessible only in stack stack table has access to P’s kernel mode). virtual memory. The syscall (trap) handler makes an indirect call through the system call dispatch table to the handler registered for the specific system call. Upcall example: Unix signals • Signals are asynchronous notifications to a process that some event of interest to it has occurred. • A process may register signal handlers for various events relating to the process. The signal handlers are procedures in user space. • To deliver a signal, the kernel redirects a user thread to execute a selected registered signal handler in user mode. • Unix signals take a default action if no handler is registered. – E.g., segmentation fault à die. Other actions: ignore, stop data data ...and upcalls Protected (e.g., signals) system calls The kernel must be bulletproof Secure kernels handle system calls verrry carefully. User program / user space Syscalls indirect through Kernel copies all syscall dispatch table user buffers arguments into by syscall number. No kernel space and direct calls to kernel trap copyout copyin validates them. routines from user space! Kernel interprets pointer arguments in What about references context of the user read() {…} to kernel data objects VAS, and copies the passed as syscall write() {…} data in/out of kernel arguments (e.g., file to kernel space (e.g., for read read or write)? and write syscalls). Use an integer index into a kernel table that points at the data object. The value is called a handle or descriptor. No direct pointers to kernel data from user space! Unix: A lasting achievement? “Perhaps the most important achievement of Unix is to demonstrate that a powerful operating system for interactive use need not be expensive…it can run on hardware costing as little as $40,000.” The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. DEC PDP-11/24 The UNIX Time-Sharing System* D. M. Ritchie and K. Thompson 1974 http://histoire.info.online.fr/pdp11.html Process management • OS offers system call APIs for managing processes. – Create processes (children) – Control processes – Monitor process execution – “Join”: wait for a process to exit and return a result – “Kill”: send a signal to a process – Establish interprocess communication (IPC: later) – Launch a program within a process • We study the Unix process abstraction as an example. – Illustrative and widely used for 40+ years! – Optional: Use it to build your own shell. Example: Unix fork The Unix fork() system call creates/launches a new thread, in its own fresh virtual address space: it creates a new process. (Thread + VAS == Process.) Strangely, the new (“child”) process is an exact clone of the calling (“parent”) process. fork Oh Ghost of Walt, please don’t sue me. Unix fork/exit syscalls int pid = fork(); Create a new process that is a clone of parent its parent. Return child process ID (pid) to parent, return 0 to child. fork parent child exit(status); Exit with status, destroying the process. Status is returned to the parent. Note: this is not the only way for a time process to exit! data data exit exit p pid: 5587 pid: 5588 fork The fork syscall returns twice: int pid; It returns a zero in int status = 0; the context of the if (pid = fork()) { new child process. /* parent */ ….. It returns the new } else { child process ID /* child */ (pid) in the context ….. of the parent. exit(status); } A simple program: sixforks … int main(int argc, char* argv) How many processes are { created by these six forks? fork(); fork(); fork(); fork(); fork(); fork(); printf("Process %d exiting.\n", getpid()); } chase$ cc –o sixforks sixforks.c getpid syscall: chase$ ./sixforks Get processID of ??? current process. chase$ Process 15220 exiting. Process 15209 exiting. Process 15232 exiting. A simple program: sixforks Process 15219 exiting. Process 15233 exiting. chase$ cc –o sixforks sixforks.c Process 15223 exiting. chase$ ./sixforks Process 15210 exiting. … Process 15191 exiting. Process 15234 exiting. Process 15200 exiting. Process 15228 exiting. int Process 15195 exiting. Process 15192 exiting. Process 15194 exiting. Process 15230 exiting. main(int argc, char* argv) Process 15197 exiting. Process 15211 exiting. { Process 15202 exiting. Process 15227 exiting. Process 15193 exiting. Process 15239 exiting. Process 15198 exiting. fork(); Process 15231 exiting. Process 15215 exiting. Process 15242 exiting. fork(); Process 15217 exiting. Process 15218 exiting. Process 15243 exiting. fork(); Process 15203 exiting. Process 15240 exiting. Chase$ Process 15212 exiting. Process 15236 exiting. fork(); Process 15196 exiting. Process 15241 exiting. Process 15222 exiting. Process 15244 exiting. fork(); Process 15213 exiting. Process 15247 exiting. fork(); Process 15221 exiting. Process 15235 exiting. Process 15224 exiting. Process 15245 exiting. printf("Process %d exiting.\n", Process 15206 exiting. Process 15250 exiting. Process 15216 exiting. Process 15248 exiting. getpid()); Process 15205 exiting. Process 15207 exiting. Process 15249 exiting. } Process 15201 exiting. Process 15204 exiting. Process 15214 exiting. Process 15238 exiting. Process 15225 exiting. Process 15251 exiting. Process 15199 exiting. Process 15237 exiting. Process 15226 exiting. Process 15252 exiting. Process 15208 exiting. Process 15253 exiting. Process 15229 exiting. Process 15246 exiting. Process 15254 exiting. sixforks: some questions • What if I want to create six children, but I don’t want my children to have children of their own? • What if I want the program to print the total number of processes created? How? (Other than by having the program do the math.) • How much memory does this program use? How many pages? • How does this test system assign process IDs? • Why do the process IDs print out of order? fork (original concept) fork in action today Fork is conceptually difficult but void syntactically clean and simple. dofork() { I don’t have to say anything about what int cpid = fork(); the new child process “looks like”: it is an if (cpid < 0) { exact clone of the parent! perror("fork failed: "); The child has a new thread executing at exit(1); the same point in the same program. } else if (cpid == 0) { The child is a new instance of the child(); running program: it has a “copy” of the } else { entire address space. The “only” change is the process ID and return value cpid! parent(cpid); } The parent thread continues on its way. } The child thread continues on its way. wait syscall Parent uses wait to sleep until the child int pid; exits; wait returns child int status = 0; pid and status. if (pid = fork()) { /* parent */ Wait variants allow wait ….. on a specific child, or pid = wait(&status); notification of stops and } else { other signals. /* child */ Recommended: use waitpid(). ….. exit(status); } Warning: the uses of the terms wait and signal should not be confused with the monitor/CV primitives of the same names. wait Process states (i.e., states of the main thread of the process) “wakeup” “sleep” Note: in modern Unix systems the wait syscall has many variants and options. A simple program: forkdeep int count = 0; main(int argc, char *argv[]) int level = 0; { count = atoi(argv[1]); void child() { dofork(); level++; output pid We’ll see later where arguments come from. output pids } if (level < count) dofork(); if (level == count) sleep(3); /* pause 3 secs */ } level==1 void parent(int childpid) { output pids level==2 wait for child to finish } chase$ ./forkdeep 4 chase$ ./forkdeep 3 30866-> 30867 11496-> 11498 30867 11498 30867-> 30868 11498-> 11499 30868 11499 30868-> 30869 11499-> 11500 30869 11500 30869-> 30870 11500 30870 11499 30870 11498 30869 11496 30868 chase$ 30867 30866 chase$ Example: Chrome browser [Google Chrome Comics] Processes in the browser Chrome makes an interesting choice here.
Recommended publications
  • Freebsd-And-Git.Pdf
    FreeBSD and Git Ed Maste - FreeBSD Vendor Summit 2018 Purpose ● History and Context - ensure we’re starting from the same reference ● Identify next steps for more effective use / integration with Git / GitHub ● Understand what needs to be resolved for any future decision on Git as the primary repository Version control history ● CVS ○ 1993-2012 ● Subversion ○ src/ May 31 2008, r179447 ○ doc/www May 19, 2012 r38821 ○ ports July 14, 2012 r300894 ● Perforce ○ 2001-2018 ● Hg Mirror ● Git Mirror ○ 2011- Subversion Repositories svnsync repo svn Subversion & Git Repositories today svn2git git push svnsync git svn repo svn git github Repositories Today fork repo / Freebsd Downstream svn github github Repositories Today fork repo / Freebsd Downstream svn github github “Git is not a Version Control System” phk@ missive, reproduced at https://blog.feld.me/posts/2018/01/git-is-not-revision-control/ Subversion vs. Git: Myths and Facts https://svnvsgit.com/ “Git has a number of advantages in the popularity race, none of which are really to do with the technology” https://chapmanworld.com/2018/08/25/why-im-now-using-both-git-and-subversion-for-one-project/ 10 things I hate about Git https://stevebennett.me/2012/02/24/10-things-i-hate-about-git Git popularity Nobody uses Subversion anymore False. A myth. Despite all the marketing buzz related to Git, such notable open source projects as FreeBSD and LLVM continue to use Subversion as the main version control system. About 47% of other open source projects use Subversion too (while only 38% are on Git). (2016) https://svnvsgit.com/ Git popularity (2018) Git UI/UX Yes, it’s a mess.
    [Show full text]
  • Getting Started With... Berkeley Software for UNIX† on the VAX‡ (The Third Berkeley Software Distribution)
    Getting started with... Berkeley Software for UNIX† on the VAX‡ (The third Berkeley Software Distribution) A package of software for UNIX developed at the Computer Science Division of the University of California at Berkeley is installed on our system. This package includes a new version of the operating sys- tem kernel which supports a virtual memory, demand-paged environment. While the kernel change should be transparent to most programs, there are some things you should know if you plan to run large programs to optimize their performance in a virtual memory environment. There are also a number of other new pro- grams which are now installed on our machine; the more important of these are described below. Documentation The new software is described in two new volumes of documentation. The first is a new version of volume 1 of the UNIX programmers manual which has integrated manual pages for the distributed software and incorporates changes to the system made while introducing the virtual memory facility. The second volume of documentation is numbered volume 2c, of which this paper is a section. This volume contains papers about programs which are in the distribution package. Where are the programs? Most new programs from Berkeley reside in the directory /usr/ucb. A major exception is the C shell, csh, which lives in /bin. We will later describe how you can arrange for the programs in the distribution to be part of your normal working environment. Making use of the Virtual Memory With a virtual memory system, it is no longer necessary for running programs to be fully resident in memory.
    [Show full text]
  • CS 350 Operating Systems Spring 2021
    CS 350 Operating Systems Spring 2021 4. Process II Discussion 1: Question? • Why do UNIX OSes use the combination of “fork() + exec()” to create a new process (from a program)? • Can we directly call exec() to create a new process? Or, do you have better ideas/designs for creating a new process? • Hints: To answer this question: think about the possible advantages of this solution. Fork Parent process Child process Exec New program image in execution 2 Discussion 1: Background • Motived by the UNIX shell • $ echo “Hello world!” • $ Hello world! • shell figures out where in the file system the executable “echo” resides, calls fork() to create a new child process, calls exec() to run the command, and then waits for the command to complete by calling wait(). • You can see that you can use fork(), exec() and wait() to implement a shell program – our project! • But what is the benefit of separating fork() and exec() in creating a new process? 3 Discussion 1: Case study • The following program implements the command: • $ wc p3.c > p4.output # wc counts the word number in p3.c • # the result is redirected to p4.output Close default standard output (to terminal) open file p4.output 4 Discussion 1: Case study • $ wc p3.c # wc outputs the result to the default standard output, specified by STDOUT_FILENO • By default, STDOUT_FILENO points to the terminal output. • However, we close this default standard output → close(STDOUT_FILENO ); • Then, when we open the file “p4.output” • A file descriptor will be assigned to this file • UNIX systems start looking for free file descriptors from the beginning of the file descriptor table (i.e., at zero).
    [Show full text]
  • The Dragonflybsd Operating System
    1 The DragonFlyBSD Operating System Jeffrey M. Hsu, Member, FreeBSD and DragonFlyBSD directories with slightly over 8 million lines of code, 2 million Abstract— The DragonFlyBSD operating system is a fork of of which are in the kernel. the highly successful FreeBSD operating system. Its goals are to The project has a number of resources available to the maintain the high quality and performance of the FreeBSD 4 public, including an on-line CVS repository with mirror sites, branch, while exploiting new concepts to further improve accessible through the web as well as the cvsup service, performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being mailing list forums, and a bug submission system. explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the III. MOTIVATION network subsystem in particular. A. Technical Goals Index Terms— Message passing, Multiprocessing, Network The DragonFlyBSD operating system has several long- operating systems, Protocols, System software. range technical goals that it hopes to accomplish within the next few years. The first goal is to add lightweight threads to the BSD kernel. These threads are lightweight in the sense I. INTRODUCTION that, while user processes have an associated thread and a HE DragonFlyBSD operating system is a fork of the process context, kernel processes are pure threads with no T highly successful FreeBSD operating system. Its goals are process context. The threading model makes several to maintain the high quality and performance of the FreeBSD guarantees with respect to scheduling to ensure high 4 branch, while exploring new concepts to further improve performance and simplify reasoning about concurrency.
    [Show full text]
  • Linux-Kernel
    linux-kernel #linux- kernel Table of Contents About 1 Chapter 1: Getting started with linux-kernel 2 Remarks 2 Versions 2 Examples 2 Installation or Setup 2 Download extract and enter to the kernel directory 2 Build the dependencies, compile the kernel and modules. 3 Chapter 2: Creation and usage of Kernel Threads 4 Introduction 4 Examples 4 Creation of kernel threads 4 Chapter 3: Event Tracing 6 Examples 6 Tracing I2C Events 6 Chapter 4: Fork System call 7 Examples 7 fork() system call 7 Chapter 5: How to find the right person for help. 9 Introduction 9 Examples 9 Find the "likely" maintainers for the FTDI USB serial converter 9 Chapter 6: Linux Hello World Device driver 10 Examples 10 An empty kernel module 10 Building and running the module 10 Chapter 7: Linux: Named Pipes(FIFO) 12 Examples 12 What is Named Pipe (FIFO) 12 Credits 13 About You can share this PDF with anyone you feel could benefit from it, downloaded the latest version from: linux-kernel It is an unofficial and free linux-kernel ebook created for educational purposes. All the content is extracted from Stack Overflow Documentation, which is written by many hardworking individuals at Stack Overflow. It is neither affiliated with Stack Overflow nor official linux-kernel. The content is released under Creative Commons BY-SA, and the list of contributors to each chapter are provided in the credits section at the end of this book. Images may be copyright of their respective owners unless otherwise specified. All trademarks and registered trademarks are the property of their respective company owners.
    [Show full text]
  • Processes and Job Control
    Processes and Job Control Hour 17 PObjectives < Definitions: process, orphan, and zombie < System processes < Process creation < Examining processes: the ps command < Job control: &, nohup, fg, bg, jobs, ( ), and kill < Exit status Copyright © 1998-2002 Delroy A. Brinkerhoff. All Rights Reserved. Hour 17 Unix Slide 1 of 12 Process Also called a job by C and Korn shells PWhen a program or executable file is loaded from disk and started running (i.e., when a command is run), it is called a process vi pid 641 < identified by a unique process ID (PID) number < has an owner vi < private data vi PA program can be loaded more than once pid 895 < creates multiple processes vi < each process has a different PID < each process may have a different owner PPIDs are unique, nonnegative integers < numbers recycle without collisions Hour 17 Unix Slide 2 of 12 System Processes Processes created during system boot P0System kernel < “hand crafted” at boot < called swap in older versions (swaps the CPU between processes) < called sched in newer versions (schedules processes) < creates process 1 P1 init (the parent of all processes except process 0) < general process spawner < begins building locale-related environment < sets or changes the system run-level P2 page daemon (pageout on most systems) P3 file system flusher (fsflush) Hour 17 Unix Slide 3 of 12 Process Life Cycle Overview of creating new processes fork init init pid 467 Pfork creates two identical pid 1 exec processes (parent and child) getty pid 467 Pexec < replaces the process’s instructions
    [Show full text]
  • Lecture 4: September 13 4.1 Process State
    CMPSCI 377 Operating Systems Fall 2012 Lecture 4: September 13 Lecturer: Prashant Shenoy TA: Sean Barker & Demetre Lavigne 4.1 Process State 4.1.1 Process A process is a dynamic instance of a computer program that is being sequentially executed by a computer system that has the ability to run several computer programs concurrently. A computer program itself is just a passive collection of instructions, while a process is the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several windows of the same program typically means more than one process is being executed. The state of a process consists of - code for the running program (text segment), its static data, its heap and the heap pointer (HP) where dynamic data is kept, program counter (PC), stack and the stack pointer (SP), value of CPU registers, set of OS resources in use (list of open files etc.), and the current process execution state (new, ready, running etc.). Some state may be stored in registers, such as the program counter. 4.1.2 Process Execution States Processes go through various process states which determine how the process is handled by the operating system kernel. The specific implementations of these states vary in different operating systems, and the names of these states are not standardised, but the general high-level functionality is the same. When a process is first started/created, it is in new state. It needs to wait for the process scheduler (of the operating system) to set its status to "new" and load it into main memory from secondary storage device (such as a hard disk or a CD-ROM).
    [Show full text]
  • List of BSD Operating Systems
    FreeBSD-based SNo Name Description A lightweight operating system that aims to bring the flexibility and philosophy of Arch 1 ArchBSD Linux to BSD-based operating systems. 2 AskoziaPBX Discontinued 3 BSDBox 4 BSDeviant 5 BSDLive 6 Bzerk CD 7 DragonFly BSD Originally forked from FreeBSD 4.8, now developed in a different direction 8 ClosedBSD DesktopBSD is a discontinued desktop-oriented FreeBSD variant using K Desktop 9 DesktopBSD Environment 3.5. 10 EclipseBSD Formerly DamnSmallBSD; a small live FreeBSD environment geared toward developers and 11 Evoke system administrators. 12 FenestrOS BSD 13 FreeBSDLive FreeBSD 14 LiveCD 15 FreeNAS 16 FreeSBIE A "portable system administrator toolkit". It generally contains software for hardware tests, 17 Frenzy Live CD file system check, security check and network setup and analysis. Debian 18 GNU/kFreeBSD 19 Ging Gentoo/*BSD subproject to port Gentoo features such as Portage to the FreeBSD operating 20 Gentoo/FreeBSD system GhostBSD is a Unix-derivative, desktop-oriented operating system based on FreeBSD. It aims to be easy to install, ready-to-use and easy to use. Its goal is to combine the stability 21 GhostBSD and security of FreeBSD with pre-installed Gnome, Mate, Xfce, LXDE or Openbox graphical user interface. 22 GuLIC-BSD 23 HamFreeSBIE 24 HeX IronPort 25 security appliances AsyncOS 26 JunOS For Juniper routers A LiveCD or USB stick-based modular toolkit, including an anonymous surfing capability using Tor. The author also made NetBSD LiveUSB - MaheshaNetBSD, and DragonFlyBSD 27 MaheshaBSD LiveUSB - MaheshaDragonFlyBSD. A LiveCD can be made from all these USB distributions by running the /makeiso script in the root directory.
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]
  • Troubleshoot Zombie/Defunct Processes in UC Servers
    Troubleshoot Zombie/Defunct Processes in UC Servers Contents Introduction Prerequisites Requirements Components Used Background Information Check Zombies using UCOS Admin CLI Troubleshoot/Clear the Zombies Manually Restart the Appropriate Service Reboot the Server Kill the Parent Process Verify Introduction This document describes how to work with zombie processes seen on CUCM, IMnP, and other Cisco UC products when logged in using Admin CLI. Prerequisites Requirements Cisco recommends that you have knowledge of using Admin CLI of the UC servers: ● Cisco Unified Communications Manager (CUCM) ● Cisco Unified Instant Messaging and Presence Server (IMnP) ● Cisco Unity Connection Server (CUC) Components Used This document is not restricted to specific software and hardware versions. The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command. Background Information The Unified Communications servers are essentially Linux OS based applications. When a process dies on Linux, it is not all removed from memory immediately, its process descriptor (PID) stays in memory which only takes a tiny amount of memory. This process becomes a defunct process and the process's parent is notified that its child process has died. The parent process is then supposed to read the dead process's exit status and completely remove it from the memory. Once this is done using the wait() system call, the zombie process is eliminated from the process table. This is known as reaping the zombie process.
    [Show full text]
  • Operating Systems Homework Assignment 2
    Operating Systems Homework Assignment 2 Preparation For this homework assignment, you need to get familiar with a Linux system (Ubuntu, Fedora, CentOS, etc.). There are two options to run Linux on your Desktop (or Laptop) computer: 1. Run a copy of a virtual machine freely available on-line in your own PC environment using Virtual Box. Create your own Linux virtual machine (Linux as a guest operating system) in Windows. You may consider installing MS Windows as a guest OS in Linux host. OS-X can host Linux and/or Windows as guest Operating systems by installing Virtual Box. 2. Or on any hardware system that you can control, you need to install a Linux system (Fedora, CentOS Server, Ubuntu, Ubuntu Server). Tasks to Be Performed • Write the programs listed (questions from Q1 to Q6), run the program examples, and try to answer the questions. Reference for the Assignment Some useful shell commands for process control Command Descriptions & When placed at the end of a command, execute that command in the background. Interrupt and stop the currently running process program. The program remains CTRL + "Z" stopped and waiting in the background for you to resume it. Bring a command in the background to the foreground or resume an interrupted program. fg [%jobnum] If the job number is omitted, the most recently interrupted or background job is put in the foreground. Place an interrupted command into the background. bg [%jobnum] If the job number is omitted, the most recently interrupted job is put in the background. jobs List all background jobs.
    [Show full text]
  • Processes in Linux/Unix
    Processes in Linux/Unix A program/command when executed, a special instance is provided by the system to the process. This instance consists of all the services/resources that may be utilized by the process under execution. • Whenever a command is issued in unix/linux, it creates/starts a new process. For example, pwd when issued which is used to list the current directory location the user is in, a process starts. • Through a 5 digit ID number unix/linux keeps account of the processes, this number is call process id or pid. Each process in the system has a unique pid. • Used up pid’s can be used in again for a newer process since all the possible combinations are used. • At any point of time, no two processes with the same pid exist in the system because it is the pid that Unix uses to track each process. Initializing a process A process can be run in two ways: 1. Foreground Process : Every process when started runs in foreground by default, receives input from the keyboard and sends output to the screen. When issuing pwd command $ ls pwd Output: $ /home/geeksforgeeks/root When a command/process is running in the foreground and is taking a lot of time, no other processes can be run or started because the prompt would not be available until the program finishes processing and comes out. 2. Backround Process : It runs in the background without keyboard input and waits till keyboard input is required. Thus, other processes can be done in parallel with the process running in background since they do not have to wait for the previous process to be completed.
    [Show full text]