{"id":23532,"date":"2023-04-20T09:41:08","date_gmt":"2023-04-20T09:41:08","guid":{"rendered":"https:\/\/www.booksofall.com\/?post_type=product&p=23532"},"modified":"2023-04-20T09:41:09","modified_gmt":"2023-04-20T09:41:09","slug":"unix-lecture-notes-chapter-07","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/fr\/unix-lecture-notes-chapter-07\/","title":{"rendered":"UNIX Lecture Notes – Chapter 07"},"content":{"rendered":"

7.1 Introduction<\/p>\n

In a typical operating systems course, a process is defined to be a program in execution, or something similar to that. This is a true and accurate abstraction. A program such as the bash shell<\/a> can have many, many instances running on a multi-user machine<\/a> and each individual instance is a separate and distinct process, although each and every one of these is executing the exact same executable \u001cle. What this definition does not tell you is what a process is in concrete terms. It is like saying that a baseball game is an instance of the implementation of a set of rules created by Alexander Cartwright in 1845 by which two teams compete against each other on a playing \u001cfield. Neither definition gives you a mental picture of the thing being defined. In this chapter, we focus on the concrete representation of a process in UNIX: how it is represented within the kernel, what kinds of resources it requires, how those resources are materialized and managed, what attributes it has, and what system calls are related to its control and management. As a \u001cfirst step we will look at processes from the command level. Afterward, we will look at how UNIX systems arrange their address spaces and manage them in virtual and physical memory. Then we will look at how processes are created and how they communicate and synchronize with each other.<\/p>\n

7.2 Examining Processes on the Command Line<\/p>\n

The ps command<\/a> is used for viewing one or more processes currently known to the operating system. I say “currently known” as opposed to “active” because the list may include processes that are technically not active, so called zombie processes. The set of options available for the ps command is very system dependent. There were different versions of it in BSD systems and in Version 7, and then there are options added by GNU<\/a>. RedHat<\/a> Linux systems support all of the historical options, and so there are many different ways to use this command in Linux. In Linux, users also have the option of running the top command. The top command is very much like ps, except that it displays the dynamic, real-time view of the state of the system. It is like the Windows task manager<\/a>, and also like a terminal-based version of the Gnome System Monitor<\/a>. Here we will describe the standard syntax rather than the BSD style or GNU syntax. The ps command without options displays the list of processes of the login id that executes it, in a short form:<\/p>\n

\"\"<\/p>\n

You will notice that it always contains a line for the command itself because it itself has to run to do its job, obviously. The -f option causes it to display a full listing:<\/p>\n

\"\"<\/p>\n

The UID column is the user login name. The PID column is the process id of the process. The PPID column is the parent process’s process id. The C field is rarely of interest; it gives processor utilization information. The STIME field is the starting time in hours, minutes, and seconds. The TIME column is the cumulative execution time, which for short commands will be zero, since the smallest unit of measurement in this column is seconds. The CMD column is the command line being executed by this process; in this case there are two: bash and “ps -f”. All command line arguments are displayed; if any are suppressed, the command will appear in square brackets:<\/p>\n

\"\"<\/p>\n

The TTY column is the controlling terminal attached to this process. Some processes have no terminal, in which case a “?” will appear.<\/p>\n

The -e option displays all processes, which will be quite long. If I want to know which process is the parent of my bash process, I can use ps -ef and \u001cfilter using grep:<\/p>\n

\"\"<\/p>\n

From this output you see that I am connected via ssh on pseudo-terminal pts\/8 and that the ssh daemon sshd is the parent of my bash process.<\/p>\n

You can learn a lot about a system just by running ps. For example, on our Linux system, the fi\u001crst few processes in the system are:<\/p>\n

$ ps -ef | head -4 UID PID PPID C STIME TTY TIME CMD root 1 0 0 Jan29 ? 00:00:01 init [5] root 2 1 0 Jan29 ? 00:00:02 [migration\/0] root 3 1 0 Jan29 ? 00:00:00 [ksoftirqd\/0<\/p>\n

\"\"<\/p>\n

whereas on our Solaris 9 server, the list is:<\/p>\n

\"\"<\/p>\n

Notice that in Solaris, the (CPU) process scheduler itself is the very first process in the system. It is absent in Linux. In all UNIX systems, the process with PID 1 is always init. In Solaris, the pageout process is responsible for writing pages to disk, and fsflush \u001dflushes system bu\u001bffers to disk.<\/p>\n

The -u and -U options are useful for viewing all of your processes or those of others in a supplied user list. The list of users must be comma-separated, with no intervening spaces. For example:<\/p>\n

\"\"<\/p>\n

While there are dozens of other options, I will only mention one more: the -o option. You can customize the output of the ps command to include any of the dozens of attributes available to be displayed using -o. The man page gives the general format for this. Some examples from the man page:<\/p>\n

\"\"<\/p>\n

Note that there are no spaces in the list. In general never use spaces in any of the lists because the shell will then treat them as separate words rather than a single word to be passed to the ps command itself.<\/p>\n","protected":false},"excerpt":{"rendered":"