Process

In our daily lives, our thinking is multitasking, but many tasks often go unnoticed. For instance, I might walk while listening to music and using my smartphone, which involves three concurrent tasks. While it seems I can consciously control all these tasks – like pausing the smartphone while crossing the street – there are underlying processes that I cannot control. When a sudden stimulus, such as an attractive person, triggers physiological responses like a racing heartbeat or rapid breathing, I can't entirely govern these reactions. While self-discipline might help restrain some responses, certain background processes like digestion and blood circulation remain beyond my control.

Contemporary operating systems, much like humans, possess multitasking capabilities. They can run numerous applications simultaneously, and each active program at a given time is a "process." Operating systems, similar to human control, can partially or completely govern some processes, while others are beyond control.

Just like human thoughts, Linux processes never truly halt; there's a constant stream of processes, large and small, running at all times. In the realm of multitasking operating systems (such as Linux/Windows), processes theoretically can't be entirely shut down – there's always some process running.

Generally defined, any running (unfinished) program, including system daemons or user-entered commands, qualifies as a process. Processes generated from commands within a user's logged-in shell are referred to as "jobs." Barring shutdown or a sleep state like Suspend to RAM, processes cannot come to a complete halt.

^ back on top ^

Processes generated from commands within a user's logged-in shell are referred to as "jobs."

Let's take the familiar example of Windows: The screenshot below shows the input of "taskmgr" in the Windows text interface, which executes the "Task Manager." Under the "Applications" column, the user's jobs are listed.

Windows Task Manager:

• Job Control
  Job control involves manipulating the behavior of jobs. Common controls include suspending a job, sending it to the background, moving a background command to the foreground, or even terminating a job. You can also adjust the priority of jobs.
  
  
• Foreground Program
  By default, when executing a command in a text interface, it runs in the foreground. You must wait for it to finish before entering other commands.Example:

  $ dd if=/dev/zero of=1g-file bs=1G count=1; seq 1 1000000

  
  

  In the above example, running dd to generate a 1GB file takes time, and only after it completes does the seq command run. The drawback of foreground programs is the necessity to wait for a program to finish before executing the next command.

  However, despite Linux being a multitasking operating system, forcing every program to wait until completion before moving to the next instruction would negate its multitasking capabilities. Certain time-consuming programs can be run in the background.

  
  
  
• Terminating a Program <CTRL+C>
  If a foreground program runs for too long or an incorrect command is entered, pressing <Ctrl+C> terminates its execution.
  
  Example:
  

  $ seq 1 1000000 1 2 3 4 Ctrl+C ←ress <Ctrl+C> to terminate the foreground program $

  
  
• Pausing a Program <CTRL+Z>
  If you wish to interrupt a command without terminating it (which would waste the current computation), you can temporarily pause it. This allows you to insert another command and later either resume the paused job using fg (bringing it to the foreground) or move it to the background using bg.
  
  Example:

  $ seq 1 1000000 1 2 3 4 Ctrl+Z ← Press <Ctrl+Z> to pause the foreground program [1]+ Stopped                seq 1 100000000 ←The program has been stopped $ mv fileA fileB ←(Insert another command) $ fg ←Resume the paused job 5 6 7 . . .

  
  
• Background Execution with &
  To begin with, placing a command in the background is simple. Just add "&" at the end of the command. For instance, in the previous example, you can put the time-consuming dd process in the background. This allows the foreground to handle other tasks.
  
  Example:

  $ dd if=/dev/zero of=1g-file bs=1G count=1 & ←Put dd in the background [1] 2680 ←The job number is [1], and the PID is 2680 $ seq 1 1000000 ←The foreground can execute other commands 1 2 3 . . .

  
  Programs (jobs) launched in the background within the logged-in shell are assigned a unique identifier called the "job number," which is displayed inside square brackets (as in the previous example, "[1]"), followed by the Process ID (PID) of the specific job (for instance, "2680" in the previous example).
  

  For different users, their job numbers operate independently. Multiple logged-in accounts might have jobs with the same job number, but they remain separate. The job number corresponds to the order of execution within the shell for each user.

  Example:

  $ dd if=/dev/zero of=1g-image bs=1G count=1 & ←← Generate a 1GB file in the background [1] 2680 ←job number [1], PID 2680 $ sleep 60 & ←Pause the entire shell for 60 seconds in the background [2] 2681 ←Job number [2], PID 2681 $ su ←Switch to superuser # updatedb & ←Run "updatedb" in the background as superuser [1] 2725 ←ob number [1] (but this is for the superuser)

  
  

  For placing multiple commands in the background and writing them on the same line, replace the semicolon ";" with an ampersand "&".

  Example:

  $ dd if=/dev/zero of=1g-image bs=1G count=1 & sleep 60 & ↵ Enter ←Place multiple commands in the background [1] 2680 [2] 2681

  
  

  Although putting programs in the background facilitates multitasking, the background program's standard output or standard error might interfere with foreground programs. In such cases, you can redirect the background program's standard output or standard error to a file.

  Example:

  $ seq 1 10000 > count.txt & ←Redirect the background program's standard output to a file [1] 2680 $ cp -r /etc /tmp 1> /dev/null 2>&1 & ←Redirect the background program's standard output and standard error to a file [2] 2681

  
  

  ^ back on top ^

• jobs : Display Background Jobs
  The jobs command is used to display the background or paused jobs within the current shell session. The job number is displayed inside square brackets "[ ]".
  
  Example:

  $ sleep 600 & [1] 2680 $ dd if=/dev/zero of=1g-file bs=1G count=1& [2] 2681 $ seq 1 1000000 1 2 3 Ctrl+Z ← Press <Ctrl+Z> to pause the command "seq 1 1000000" [3]+ Stopped                seq 1 100000000 $ jobs ←Display background jobs [1] Running sleep 600 & ←ob number inside square brackets [ ] [2]- dd if=/dev/zero of=1g-file bs=1G count=1 & ←he second-to-last job has a "-" [3]+ Stopped seq 1 1000000 ←The last job has a "+"

  
  To only list paused jobs, you can use jobs -s. To list only background jobs, use jobs -r. To list jobs along with their PIDs, use jobs -l. To only list the PIDs of the jobs, use jobs -p.
  
  
  • Managing Jobs
    When executing the jobs command, a "+" and a "-" are displayed after the square brackets "[ ]" for the last and second-to-last job, respectively. This helps specify which job to manage using commands like bg、fg or kill . For instance, kill %+ kills the last job. Here's a summary of commonly used symbols to specify jobs:
    
    

    Symbol	Description
    "%+" or "+" or " %%"	Last job
    "%-" or "-"	Second-to-last job
    "%#" (# is the job number)	Specified job number
    "%CMD" (CMD is the command name)	Specified by command name
    "%?STRING" (STRING is a string)	Specified by contained string

    
    Example:

    $ fg %- ←Bring the second-to-last job to the foreground $ fg %4 ←Bring the job with job number 4 to the foreground $ kill %cp ←Terminate jobs starting with "cp" (e.g., cpp or cp) $ bg %?100 ←Put the job containing "100" in the background to continue execution (e.g., sleep 10000) $ jobs -s -l ←List paused jobs along with their PIDs

  
  

  ^ back on top ^

• bg - Resuming Suspended Jobs in the Background
  When a foreground program is paused, you can use the bg (background) command to quietly resume the suspended program in the background. By default, if you don't specify a job number, bg or fg will operate on "%+", which refers to the last job running in the background. Example:

  $ seq 1 1000000 1 2 3 CTRL+Z ←Press <CTRLl+Z> to pause the foreground program [1]+ Stopped                seq 1 100000000 ←The current program is paused $ bg ← Resume the paused program and let it run in the background 4 5 . . .

  
  

  Since the job is running in the background, you can't use <CTRL-Z> or <CTRL-C> to pause or terminate it.

  Example:

  $ bg %3 ←Bring job number 3 to the background to continue running

  
  
• fg : Bringing Jobs to the Foreground
  Suspended or backgrounded commands can be brought to the foreground using the fg (foreground) command. This resumes the execution of a paused job.Example:

  $ seq 1 1000000 1 2 3 CTRL+Z ←Press <CTRLl+Z> to pause the foreground program [1]+ Stopped                seq 1 100000000 ←The current program is paused $ fg ←Resume the paused program and bring it to the foreground 5 6 . . . $ fg + ←Bring the last job to the foreground $ fg ←Same as above $ fg %5 ←Bring the command with job number 5 to the foreground $ fg %gzip ← Bring the `gzip` command to the foreground

  
  Using bg and fg commands allows you to manage suspended and backgrounded jobs, controlling their execution state and bringing them back to the foreground as needed.
  
  

  ^ back on top ^

• kill : Terminate Processs
  In Unix-like operating systems, "signals" are commonly used as a means of communication between processes. Signals inform a process that an event has occurred, and the operating system responds accordingly. Signals are sometimes referred to as "soft interrupts."

  For instance, pressing <CTRL-C> sends a signal called "SIGINT" to a process. When the operating system detects this signal, it interrupts the normal control flow of the process and handles it based on the process's defined exception handling for "SIGINT." In most cases, a process receiving "SIGINT" will be terminated forcefully by the operating system.

  The kill command is used to send signals to processes, telling the operating system to handle a particular event. Most often, this results in terminating the process. However, the functionality of kill extends beyond this. By using kill -l (lowercase "L"), you can list the available types of signals.

  Example:
  

  $ kill -l ←List all signal numbers 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE 9) SIGKILL      10) SIGUSR1     11) SIGSEGV     12) SIGUSR2 13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGSTKFLT 17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP 21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU 以下略

  
  

  While kill can send various signals to processes, the way different processes handle these signals varies. If a process receives a signal that it hasn't defined a specific response for, the operating system's behavior may differ. In some cases, the process might be terminated, while in others, it might be ignored. However, signals like "SIGKILL" and "SIGSTOP" cannot be ignored. Processes receiving "SIGKILL" must be terminated, while those receiving "SIGSTOP" are effectively frozen and cannot execute.

  The basic usage of the kill command involves the "-s" option followed by a signal. In cases where a process cannot be terminated, you can use kill -s SIGKILL to terminate it without any mercy. You can also use the numerical values listed by kill -l to replace the signal names. For instance, kill -s SIGKILL is equivalent to kill -9.

  Example:
  

  $ seq 1000000000 > /dev/null & ←Generate a background process [1] 21533 $ kill -s SIGINT %+1 ← Send a "SIGINT" signal to the background process (equivalent to kill -s SIGINT or kill -2) [1]+ Interrupt seq 1000000000 > /dev/null ←he background process is interrupted $ seq 1 1000000 ←Output 1 ~ 1000000 1 2 3 CTRL+Z ←Press <CTRLl+Z> to pause the program $ kill -s SIGCONT %+1 ← Send a "SIGCONT" (continue) signal to the paused program 4 ←Output continues 5 6 . . .

  
  
  Example:
  

  $ kill -s SIGKILL %2 ← Kill job number 2 $ kill -9 1234 ←Kill process with PID 1234

  
  If a user accidentally starts a background process that runs indefinitely and cannot be interrupted (e.g., seq 1 10000000 &), they can log in to another terminal session and use ps USER_NAME to find the PID of the persistent background process. Then, they can use the kill command to handle it.
  
  Other commonly used Signals in conjunction with kill are as follows:
  

  Value	SIGNAL Name	Explanation
  2	SIGINT	Terminate the program, equivalent to pressing <CTRL-C>, so any command interruptible by CTRL-C can be terminated using this Signal.
  3	SIGQUIT	Similar to pressing <CTRL-> to terminate the program.
  9	SIGKILL	Forcefully terminate the process.
  15	SIGTERM	This is the default value. When a process receives this Signal, it usually saves necessary data and shuts down. The default method for shutting down processes during system shutdown is to use this value. If unsuccessful, (9)SIGKILL may be used.
  17	SIGCHLD	Notify the parent process that a child process has terminated
  18	SIGCONT	Resume the action that was paused by Signal (19)SIGSTOP or (2)SIGTSTP.
  19	SIGSTOP	Temporarily pause the process. It can be resumed later using Signal (18)SIGCONT. Unlike (20)SIGTSTP, this Signal cannot be ignored.
  20	SIGTSTP	Similar to pressing <CTRL-Z>, but unlike (19)SIGSTOP, some processes may ignore this Signal.

  
  Example:

  $ kill -9 %3 ←Forcefully terminate job #3 $ kill -s SIGSTOP 1234 ←Pause the process with PID=1234 $ kill -s SIGCONT 1234 ←Resume the process with PID=1234s $ kill %gzip ←Terminate the job named 'gzip'

  
  
  
  • killall : Massacre Processes
    If there are too many processes of the same command, manually killing them one by one with kill can be tiresome. This is where killall comes in.
    
    Commonly used options:
    "-I": Ignore case sensitivity.
    "-i": Interactively prompt before terminating each process.
    "-l": List the available Signal types.
    "-r": Use regular expressions for matching.
    "-s": Specify the Signal to be sent.
    "-u": Specify the user whose executed processes should be terminated.
    "-o": Specify the time before the specified point.
    "-y": Specify the time after the specified point.
    
    
    Example:

    Generating different processes $ dd if=/dev/zero of=1g-file bs=1G count=1 & [1] 2890 $ sleep 1000& [2] 2891 $ sleep 2000& [3] 2892 $ sleep 3000& [4] 2895 $ jobs ←View the newly generated processes [1]   Running                 dd if=/dev/zero of=1g-file bs=1G count=1 & [2]   Running                 sleep 1000 & [3]-  Running                 sleep 2000 & [4]+  Running                 sleep 3000 & $ killall sleep ←Terminate all processes with the name "sleep," sparing others [2]   Terminated              sleep 1000 [3]-  Terminated              sleep 2000 [4]+  Terminated              sleep 3000 $ jobs ←Verify [1]+  Running                 dd if=/dev/zero of=1g-file bs=1G count=1 &

    
    
    

^ back on top ^

During the runtime of Unix/Linux, any program that is currently executing and utilizing system resources, including user jobs and system daemon programs, is referred to as a process.

Given that Unix-like systems are multi-user and multi-tasking environments, processes are more intricate compared to jobs. There are specific terms related to processes that should be understood.

• PID (Process ID)
  While the system is operational, various processes come into existence and cease to exist. To uniquely identify and manage each of these processes, the system assigns a distinct and non-repeating identifier called the "PID" (Process ID), which aids in identification and management.
  
  
• Parent Process and PPID
  With the exception of the init process, every process has a parent process, which is indicated by the "PPID" (Parent Process ID). The PPID represents the identifier of the parent process.

  To determine the PPID, you can utilize the command echo $PPID, or you can employ the pstree command to visualize the process hierarchy.

  Example:
  

  $ echo $$ ←Display the PID of the current shell 2592 $ echo $PPID ←Display the PPID of the shell 2588

  
  
• Child Processes
  When a process spawns another process, the spawned process is referred to as a child process. The parent-child relationship between processes is relative. For example, just as a father is the "parent" of his child, he is also the "child" of his own father.

  For example, to create a ".txz" tarball file, the tar command will use the xz program for compression (thus involving two processes: tar and xz). From the perspective of the tar command, it spawns a child process, which is the xz process responsible for compression. However, from the perspective of the xz program, its parent process is the tar process that initiated the compression.
  
  

  • pstree : Display Process Relationship Tree
    The pstree command is a useful tool for visualizing the relationships between parent and child processes. The "-p" option displays the PIDs, while the "-s" option displays parent processes.Example:
    

    $ tar -Jcvf file.txz /etc &> /dev/null & ←Execute the tar command in the background, compressing with xz after archiving [1]14855 $ pstree -ps 14855 ←Observe the parent-child process relationship and their PIDs systemd(1)───gnome-terminal-(14248)───bash(14257)───tar(14855)───xz(14859)

    
    In te above example, the PID of the tar process is "14855," and its parent and child processes are bash and xz, respectively.
    
    
• process group & pgid
  A "process group" consists of one or more processes running together. One common example is a pipeline, where multiple processes are connected in sequence, such as in the command ls -F /etc | grep -v '/$' | less. In this command, three processes ls、grepand less) form a "process group", and this process group is identified by its "pgid" (process group ID).

  Creating a process group helps in managing processes efficiently. For instance, sending a signal to a process group using the kill command will affect all processes within that group. The ps command is commonly used to identify the pgid.

  Exampe:

  $ seq 0 100000000 | grep '[[:digit:]]' | tr '0-9' 'A-J' > /dev/null & [1] 29868 $ ps -o pid,pgid,comm ← Observe pid & pgid PID  PGID COMMAND 2564  2564 bash 29866 29866 seq 29867 29866 grep 29868 29866 tr 29874 29874 ps $ kill -SIGTERM -29866 ← The preceding "-" indicates the target is "pgid"

  
  In the above example, the pgid of seq, grep, and tr is "29866," indicating that they belong to the same process group.
  
  
  • process group leader
    Each process group has a leader called the "process group leader." In the example above, the process seq leads grep and tr. The simplest way to identify the process group leader is if PID equals PGID. (In the example, the PID of seq is 29866, and its PGID is also 29866.)

    If a process is not part of a pipeline, its PID is also equal to its PGID, and it leads itself.

• session and SID
  A "session" refers to all the process groups and processes associated with a single login shell. A session can include multiple background processes but only one foreground process. A login shell does not necessarily have to be tied to a physical terminal (tty); it can also be connected through a serial line, network, or other forms of pseudo-terminals (virtual terminals).

  A session is itself a process, typically the login shell, and its unique identifier is called the "session ID" or "SID." Any processes generated by the same user after logging in share the same SID. The ps command can be used to identify the SID.

  Example:
  

  $ sleep 1000 & [1] 2847 $ seq 0 100000000 |  tr '0-9' 'A-J' > /dev/null & [2] 2849 $ ps -o pid,sid,comm ←Observe pid & sid (Should be the same if not logged out) PID   SID COMMAND 2711  2711 bash 2847  2711 sleep 2848  2711 seq 2849  2711 tr 2850  2711 ps

  
  Job control essentially involves controlling processes within the same SID. For instance, when user "john" logs in, using the jobs command will list only the jobs belonging to user "john" and not those of user "root." Different logins result in different SIDs, even if the same user logs in on different terminals.
  
  
  • session leader
    A session leader is typically the login shell, and its distinguishing feature is that its PID equals its SID. In the above example, the "bash" process is the session leader (usually the login shell).
    
    
• init : Ancestral Process
  When Linux boots up, the first process created is "init," and its PID is always 1. Init is the ancestor of all processes, as it has no parent process. If a process's parent process unexpectedly dies, the process becomes an "orphaned process." In this case, init will automatically adopt these orphaned processes and become their parent process.
  
  
• Zombie Process
  Zombie processes, also known as "defunct" processes, may occur when there is a communication problem between parent and child processes. A zombie process occupies system resources. While a small number of zombie processes might not have a significant impact, a large number can severely affect system performance, potentially leading to system crashes.

  Zombie processes are a theoretical issue in other operating systems as well. Hence, the urban legend that occasionally restarting devices like phones, computers, or routers can help maintain smooth operation might have some validity. (I vaguely recall that home routers can be set to restart daily at a certain time.)

  Zombie processes occur when a child process abruptly terminates for various reasons, and the parent process fails to perform the necessary cleanup to recover the resources used by the child process, resulting in a "zombie."

  
  
• fork and exec
  Processes are reproduced asexually and can generate child processes without mating. Fortunately, humans reproduce sexually; otherwise, life might be less enjoyable! 😉

  All processes originate from init through asexual reproduction. When a process "forks," it creates a copy of itself, resulting in a child process. The "fork" name originates from the Unix system call, where using "fork( )" in a process leads to the creation of a new process, thus achieving asexual reproduction. The child process carries out different tasks, and it is given a unique PID to distinguish it from the parent process.

  The simplest example of a fork in a command-line environment is executing a new shell.

  Example:
  

  $ echo $$ ← Display the PID of the current shell 2563 2563 $ bash ← Execute another shell $ echo $$ $PPID ← Display the PID and PPID of the current shell 2592 2563 ← The current PPID = "2563," which is the PID of the previous shell

  
  Some commands, like newgrp, execute a new shell as well, demonstrating the same principle.
  
  
  • exec
    In some species, like salmon, the parent dies after giving birth to the next generation. Similarly, the ,exec command creates a new process, and the parent process disappears, essentially replacing the parent with the child.

    The exec command originates from the system call "exec( )", and it is used to replace an existing process with a new one. If a parent process is no longer needed after creating a child process, you can use exec to replace the parent.

    $ echo $$ $PPID ← View the PID and PPID of the current shell 2592 2563 $ chsh -l ← View available shell options /bin/csh /bin/sh /bin/bash /sbin/nologin $ exec csh ←Use "exec" to replace the current shell with a new "csh" shell (using the "exit" command won't return to the original shell) % echo $$ $PPID ← View the PID and PPID of the new "csh" shell 2592 2563

    
    In the example above, the new "csh" shell has the same PID and PPID as the original shell.
    

^ back on top ^

• daemon
  The term "daemon" (or "demon") comes from Latin and originally referred to a guardian spirit or deity. In medieval times, Europeans commonly believed that everyone had a guardian spirit protecting them. Later, some operating systems adopted the term "daemon" to describe processes that continuously run in the background and perform essential system tasks, akin to the concept of a system's guardian spirit.

  In Linux, a "daemon" is a special type of process that starts running in the background when the system boots up. Daemons are designed to be long-running and crucial for the proper functioning of the operating system, similar to the vital functions of a heartbeat or breathing in a human body. They continuously watch over and accompany the operating system throughout its operation.

  Most daemons in Linux are related to networking services and hardware control. Traditionally, daemon processes are named with a "d" at the end to easily identify them. For example, "telnetd" or "sshd" (for remote login services) and "syslogd" (for system logging) are all daemon processes. You can use commands like pstree or ps to observe processes ending with "d" to identify most daemons.

  Despite being different from typical user processes, daemons are still processes. One distinct characteristic of daemons is that their parent process is init, and they always run in the background, remaining active and essential for the system's operation.

^ back on top ^

When used without any options, ps output is similar to jobs and displays processes associated with the same session ID as the user.

The ps command is used to display information about processes. In the above example, it shows the Process ID (PID), Terminal (TTY), Time, and Command (CMD) of the running processes.

Example:

The ps aux command displays detailed information about all processes. In the example above, it is used in combination with grep to find zombie processes. Zombie processes are indicated by the "STAT" column showing "Z" (defunct).

The ps -o command is used to customize the output format. In the above example, it specifies the columns to display, including PID, Parent PID (PPID), Process Group ID (PGID), Nice value (NI), Terminal (TTY), and Command (COMM).

^ back on top ^

By default, when you run top, it will continuously update real-time information every 5 seconds (with the most CPU-intensive process at the top for easy identification) until you press q to exit. top is an interactive tool, and you can perform actions such as renicing or killing processes using r or k, toggling task/CPU information with t, toggling memory information with m, and more. For a complete list of key commands, you can press h.

• The first line is obtained from the uptime command and displays the current system time. The subsequent fields show the system's uptime, such as "36 days, 1:08" (indicating the system has been running without a crash for 36 days, 1 hour, and 8 minutes), and the number of logged-in users, which is "2" in this case.

  The last field, "load average 0.16, 0.02, 0.01," presents the system's load averages for the last 1, 5, and 15 minutes, respectively. If these values exceed 5, it may suggest a system overload.

  Additionally, you can toggle the display of this line by pressing the l key (lowercase L).

  
  
  
• The second line provides a summary of the total number of processes, including running, sleeping, stopped, and zombie processes.
  
  
• The third line displays CPU usage information for various categories::[註 1.3]

  sy	System CPU time
  ni	User time with adjusted priority (nice value)
  id	Idle CPU time
  wa	CPU time spent waiting for I/O operations (input/output wait)
  hi	CPU time spent handling hardware interrupts
  si	CPU time spent handling software interrupts
  st	Steal time, indicating time spent by a virtual CPU while the hypervisor is servicing other virtual CPUs

  
  You can toggle the display of these two lines (second and third) by pressing the t key.
  
  
• The fourth line presents system memory information, including total, used, and free memory, as well as buffer usage.
  
  
• The fifth line provides swap space information, including total, used, and free swap space.
  
  
• Starting from the sixth line, detailed information about individual processes is displayed in 12 columns, including:
  

  PID	process ID
  USER	User associated with the process
  PR	Process priority (niceness value)
  NI	Nice value of the process
  VIRT	Virtual memory usage (in kilobytes)
  RES	Resident memory usage (in kilobytes)
  SHR	Shared memory usage (in kilobytes)
  S	Process status D = uninterruptible sleep R = running S = sleeping T = stopped Z = zombie
  %CPU	CPU usage percentage by the process
  %MEM	Memory usage percentage by the process
  TIME+	Total CPU time used by the process (in 1/100 seconds)
  COMMAND	Process name or command.

  
  To limit the displayed processes, you can use the "-p" option followed by the PID(s) you want to monitor, as demonstrated in the example:
  

^ back on top ^

The nice command can be used to set the priority (niceness value) of a process, ranging from -20 to 19, where lower values indicate higher priority. Only the root user can set negative values. If no specific niceness value is assigned using nice, it defaults to 0. Additionally, the parent process's priority is inherited by its child processes.

To set the niceness value of a process, use the syntax: nice -n # COMMAND (# represents the niceness value, ranging from -20 to 19). However, only the root user can set values smaller than 0.

• renice
  對於已執行的 process 如要改變 niceness 值可用 renice,對非 root 用戶 renice 值只能越設越大(越大優先權越低)用法為
  renice [NICE_VALUE] [-p PID][-u USER][-g GROUP_NAME]。
  
  For running processes, you can use the renice command to change their niceness value. Non-root users can only increase the niceness value (lowering the priority), and the syntax is as follows:
  renice [NICE_VALUE] [-p PID][-u USER][-g GROUP_NAME]
  
  Example:
  

  $ renice 6 -p 2632 ←Change the niceness of PID 2632 to 6 2632: old priority 0, new priority 6

  
  

  During times of high load, appropriately adjusting the process priority can prevent certain processes from monopolizing resources. In the following experiment, we intentionally create three endlessly running processes to consume resources and then use renice to allocate resources.

  Example: (Create 3 processes to consume resources)

  $ dd if=/dev/zero of=/dev/null bs=1 count=100G & [1] 2915 $ seq 0 9999999999 > /dev/null & [2] 2926 $ yes > /dev/null & [3] 2929

  
  Next, we use top to observe the resource consumption:
  

  $ top -p 2915,2926,2929   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               2915 aaa       20   0  3956  552  472 R 33.0  0.1   2:34.52 dd if /dev/zero of 2929 aaa       20   0  3796  456  400 R 33.0  0.1   1:18.53 yes                 2926 aaa       20   0  3800  548  488 R 32.6  0.1   1:33.64 seq 0 9999999999

  
  

  Observing the three processes in the above example, each consumes about 33% of the CPU resources, almost completely utilizing the CPU time.

  Suppose we believe that the dd process is consuming too many resources, causing other processes to be sluggish. In that case, we can use renice to decrease its priority and then observe the results:

  $ renice 15 2915 2915: old priority 0, new priority 15 $ top -p 2915,2926,2929   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               2926 aaa       20   0  3800  548  488 R 45.3  0.1  12:16.22 seq 0 9999999999   2929 aaa       20   0  3796  456  400 R 45.3  0.1  12:01.15 yes                2915 aaa       35  15  3956  552  472 R  1.7  0.1   8:07.17 dd if /dev/zero of

  
  After these actions, the process that was reniced to a value of 15 now only occupies 1.7% of the CPU, while the other two processes have their CPU usage increased to around 45%.
  

^ back on top ^

In Unix-like systems, the philosophy is that "everything is a file," and this includes the FIFO data type. However, it's important to note that the size of a FIFO file is always 0, as it doesn't occupy physical disk space.

How can we use this FIFO "file"? The following example demonstrates a simple use case, using a named pipe to transform numbers into letters.

This example illustrates communication between different processes using a FIFO data stream, without the need for intermediate media.

Another practical example involves using named pipes as a medium for transferring compressed data:

Named pipes can be manipulated similarly to regular files and can be removed using the rm command.

The mkfifo command can also be used to set permissions for the named pipe file, as shown in the following example:

^ back on top ^

"Process substitution" is a technique that allows you to treat the output/input of different processes as if they were files. This is particularly useful when you want to compare or manipulate the output of commands in a file-like manner. One common use case is using process substitution with the diff command to compare the results of two commands, where regular file comparison wouldn't work.

The syntax for process substitution is "< (COMMAND)", and it creates a temporary named pipe to pass the output of "COMMAND" to another command as if it were a file.Note that there should be no space between "<" and "(".

Here's an example that demonstrates process substitution by comparing the uppercase versions of two files using the diff command:

In reality, process substitution uses named pipes behind the scenes to facilitate communication between different processes.

In this example, the process substitution creates a named pipe ("/dev/fd/63") in the background.

Here's a more concise example to illustrate the concept:

1. Create a named pipe (/dev/fd/63).[Note 1.5]
   
2. Run diff file1 /dev/fd/63 & in the background.
3. Execute uniq file2 > /dev/fd/63。
4. Delete the named pipe ("/dev/fd/63") after processing is complete.

^ back on top ^