{"id":245,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:40","modified_gmt":"2020-08-22T20:26:40","slug":"this-is-the-page-title-toplevel-80","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=245","title":{"rendered":"The Life Cycle of Processes"},"content":{"rendered":"\nThe Life Cycle of Processes<\/title>\n<p>\nFrom the time a process is created with a\nfork() until it has completed its job and disappears\nfrom the <glossary>process table<\/glossary>,\n it goes through many different states. The state a\nprocess is in changes many times during its “life.” These changes can\noccur, for example, when the process makes a <glossary>system call<\/glossary>,\n it is someone else’s\nturn to run, an <glossary>interrupt<\/glossary>\noccurs, or the process asks for a resource that is\ncurrently not available.\n<\/p>\n<p>\nA commonly used model shows processes operating\nin one of six separate states, which you can find in sched.h:<\/p>\n<ol>\n<li>executing in user mode<\/li>\n<li>executing in <glossary>kernel<\/glossary> mode<\/li>\n<li>ready to run<\/li>\n<li>sleeping <\/li>\n<li>newly created, not ready to run, and not\nsleeping <\/li>\n<li>issued exit <glossary>system call<\/glossary>\n(zombie)<\/li><\/ol>\n<p>\nThe\nstates listed here describe what is happening conceptually and do not indicate\nwhat “official” state a process is in. The official states are listed below:\n<\/p>\n<p>\n<table border=0 CELLPADDING=0 CELLSPACING=2 >\n<tr><td>TASK_RUNNING<\/td><td>task (process) currently running<\/td>\n<tr><td>TASK_INTERRUPTABLE<\/td><td>process is sleeping but can be woken up (interrupted)<\/td>\n<tr><td>TASK_UNINTERRUPTABLE  <\/td><td>process is sleeping but can <strong>not<\/strong> be woken up (interrupted)<\/td>\n<tr><td>TASK_ZOMBIE<\/td><td>process terminated but its status was not collected (it was not waited for)<\/td>\n<tr><td>TASK_STOPPED<\/td><td>process stopped by a debugger or job control<\/td>\n<tr><td>TASK_SWAPPING<\/td><td>(removed in 2.3.x kernel)<\/td>\n<\/table>\n<p>\nTable – Process States in sched.h\n<\/p>\n<p>\nIn my list of\nstates, there was no mention of a process actually being on the processor\n(TASK_RUNNING). Processes that are running in <glossary>kernel<\/glossary>\nmode or in <glossary>user mode<\/glossary> are both in the\nTASK_RUNNING state. Although there is no 1:1\nmatch-up, I hope you’ll see what each state means as we go through the following\ndescription. You can see how this all looks graphically in the figure\nbelow.\n<\/p>\n<p>\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/procflowa.gif',408,608)\" >\n<img loading=\"lazy\" decoding=\"async\" src=\"procflowc.gif\" width=\"608\" height=\"408\" border=\"0\" usemap=#procflow_map>\n<\/a>\n<map name=\"procflow_map\">\n<area shape=\"CIRCLE\" coords=\"125,110,60\" HREF=\"popup#Process flow#A process is a <i>zombie<\/i> when it is still in the process table, and is ready to be cleaned up.”>\n<area shape=\"CIRCLE\" coords=\"121,263,62\" href=\"popup#Process flow#A process is typically put to sleep when it is waiting on an extra event, like getting data from the hard disk.\">\n<area shape=\"CIRCLE\" coords=\"449,73,61\" href=\"popup#Process flow#Processes running in user mode are generally doing their normal work.\">\n<area shape=\"CIRCLE\" coords=\"366,273,56\" HREF=\"popup#Process flow#When a process is <i>read to run<\/i> it is waiting for a turn on the processor.”>\n<area shape=\"RECT\" coords=\"192,270,292,306\" href=\"popup#Process flow#When the appropriate event occurs (i.e. the data is ready), the process receives a wake up signal, but does not immediately run.\">\n<area shape=\"RECT\" coords=\"298,161,390,213\" href=\"popup#Process flow#When a context switch occurs, another process gets a turn on the processor.\">\n<area shape=\"CIRCLE\" coords=\"247,176,60\" href=\"popup#Process flow#A process running in kernel mode has extra privieldges.\">\n<area shape=\"RECT\" coords=\"274,43,382,103\" href=\"popup#When a process makes a system call or an interrupt occurs, the process switches to kernel mode.\">\n<area shape=\"RECT\" coords=\"403,240,514,266\" HREF=\"popup#Process flow#When a process is <i>read to run\/<i> it is waiting for a turn on the processor.”>\n<area shape=\"RECT\" coords=\"481,33,586,83\" href=\"popup#Process flow#Processes running in user mode are generally doing their normal work.\">\n<area shape=\"RECT\" coords=\"227,2,303,32\" href=\"popup#Process flow#When an interrupt occurs when a process is in kernel mode, the process continues to run in kernel mode.\">\n<area shape=\"CIRCLE\" coords=\"503,361,57\" HREF=\"popup#Process flow#A new process is typically created by the fork-exec pair and first goes into the <i>read-to-run<\/i> state before it gets a turn to run.”>\n<area shape=\"RECT\" coords=\"460,280,552,315\" HREF=\"popup#Process flow#A new process is typically created by the fork-exec pair and first goes into the <i>read-to-run<\/i> state before it gets a turn to run.”>\n<area shape=\"RECT\" coords=\"1,254,65,278\" href=\"popup#Process flow#A process is typically put to sleep when it is waiting on an extra event, like getting data from the hard disk.\">\n<area shape=\"RECT\" coords=\"190,220,294,263\" href=\"popup#Process flow#A process running in kernel mode as extra privieldges.\">\n<\/map>\n<p>\n<icaption>Image – Process states(<b>interactive<\/b>)<\/icaption>\n<p>\nA newly created process enters the system in state 5.\nIf the process is simply a copy of the original process (a\nfork but no exec), it then begins to run in the state that the original process was in (1\nor 2). (Why none of the other states? It has to be running to <glossary>fork<\/glossary>\na new process.) If an exec() is made, then this process will end up in\n<glossary>kernel<\/glossary> mode (2). It is possible that the fork()-exec() was done in\nsystem mode and the process goes into state 1. However, this highly unlikely.\n<\/p>\n<p>\nWhen a process is running, an <glossary>interrupt<\/glossary>\nmay be generated (more\noften than not, this is the system clock) and the currently running process is\npre-empted (3). This is the same state as state 3 because it is still ready to\nrun and in main memory. The only difference is that the process was just kicked\noff the processor.\n<\/p>\n<p>\nWhen the process makes a <glossary>system call<\/glossary>\nwhile in user mode\n(1), it moves into state 2 where it begins to run in <glossary>kernel<\/glossary>\nmode. Assume at this\npoint that the <glossary>system call<\/glossary>\nmade was to read a file on the hard disk. Because the\nread is not carried out immediately, the process goes to sleep, waiting on the\n<i>event<\/i> that the system has read the disk and the data is ready. It is now\nin state 4. When the data is ready, the process is awakened. This does not mean\nit runs immediately, but rather it is once again ready to run in main memory\n(3).\n<\/p>\n<p>\nIf a process that was asleep is awakened (perhaps when the data is\nready), it moves from state 4 (sleeping) to state 3 (ready to run). This can be\nin either <glossary>user mode<\/glossary>\n(1) or <glossary>kernel<\/glossary>\nmode (2).\n<\/p>\n<p>\nA process can end its life by\neither explicitly calling the exit()\nsystem call or having it called for them. The\nexit() <glossary>system call<\/glossary>\nreleases all the data structures\nthat the process was using. One exception is the slot in the <glossary>process table<\/glossary>,\nwhich is the responsibility of the init\nprocess. The reason for hanging around is that the slot in the <glossary>process table<\/glossary>\nis\nused for the exit code of the exiting process. This can be used by the parent\nprocess to determine whether the process did what it was supposed to do or\nwhether it ran into problems. The process shows that it has terminated by\nputting itself into state 8, and it becomes a “zombie.” Once here, it\ncan never run again because nothing exists other than the entry in the process\ntable.\n<\/p>\n<p>\nThis is why you cannot “kill” a zombie\nprocess. There is nothing there to kill. To kill a process, you need to send it\na <glossary>signal<\/glossary>\n(more on signals later). Because there is nothing there to receive or\nprocess that <glossary>signal<\/glossary>,\n trying to kill it makes little sense. The only thing to do\nis to let the system clean it up.\n<\/p>\n<p>\nIf the exiting process has any children,\nthey are “inherited” by <glossary>init<\/glossary>.\nOne value stored in the process structure is the <glossary>PID<\/glossary>\nof that process’ parent\nprocess. This value is (logically) referred to as the <i>parent process ID<\/i>\nor <glossary>PPID<\/glossary>.\n When a process is inherited by init, the value of its <glossary>PPID<\/glossary>\nis changed to 1 (the <glossary>PID<\/glossary>\nof\ninit).\n<\/p>\n<p>\nA process’ state change can cause a\ncontext switch in several different cases. One case is when the process\nvoluntarily goes to sleep, which can happen when the process needs a resource\nthat is not immediately available. A very common example is your <glossary>login<\/glossary>\n<glossary>shell<\/glossary>.\nYou type in a command, the command is executed, and you are back to a shell\nprompt. Between the time the command is finished and you input your next\ncommand, a very long time could pass – at least two or three seconds.\n<\/p>\n<p>\nRather than constantly checking the keyboard for input, the <glossary>shell<\/glossary>\nputs itself to sleep while waiting on an <glossary>event<\/glossary>.\nThat event might be an <glossary>interrupt<\/glossary> from the\nkeyboard to say “Hey! I have input for you.” When a process puts\nitself to sleep, it sleeps on a particular <i>wait channel <\/i>(WCHAN). When the\nevent that is associated with that <glossary>wait channel<\/glossary>\noccurs, <i>every<\/i> process\nwaiting on that <glossary>wait channel<\/glossary>\nis woken up. To find out what wait channels processes are waiting on for your system\nsee the section on <tutorial id=174>system monitoring<\/tutorial>.\n<\/p>\n<p>\nThere is probably only one\nprocess waiting on input from your keyboard at any given time. However, many\nprocesses could be waiting for data from the hard disk. If so, there might be\ndozens of processes all waiting on the same <glossary>wait channel<\/glossary>.\n All are woken up when\nthe hard disk is ready. It may be that the hard disk has read only the data for\na subset of the processes waiting. Therefore, if the program is correctly\nwritten, the processes check to see whether their data is ready for them. If\nnot, they put themselves to sleep on the same <glossary>wait channel<\/glossary>.\n<\/p>\n<p>\nWhen a\nprocess puts itself to sleep, it is <i>voluntarily<\/i> giving up the <glossary>CPU<\/glossary>.\n It may\nbe that this process had just started its turn when it noticed that it didn’t\nhave some resource it needed. Rather than forcing other processes to wait\nuntil the first one gets its “fair share” of the <glossary>CPU<\/glossary>,\n that process is\nnice and lets some other process have a turn on the <glossary>CPU<\/glossary>.\n<\/p>\n<p>\nBecause the\nprocess is being so nice to let others have a turn, the <glossary>kernel<\/glossary>\nwill be nice to\nthe process. One thing the <glossary>kernel<\/glossary>\nallows is that a process that puts itself to\nsleep can set the priority at which it will run when it wakes. Normally, the\nkernel process scheduling algorithm calculates the priorities of all the\nprocesses. In exchange for voluntarily giving up the <glossary>CPU<\/glossary>,\n however, the process\nis allowed to choose its own priority.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Life Cycle of Processes From the time a process is created with a fork() until it has completed its job and disappears from the process table, it goes through many different states. The state a process is in changes … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=245\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-245","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=245"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/245\/revisions"}],"predecessor-version":[{"id":747,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/245\/revisions\/747"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}