In computing, a process is an instance of a computer program that is being executed.
Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently.
In the operating system Unix, every process(except the very first one) is created when a process creates a new process.
Those 2 processes establish a relationship where:
- parent process is the process that created the new process
- child process is the newly-created process.
Every process (except the very first one):
- has one parent process, and
- can have many child processes.
A child process is a process created by another process(the parent process).
A child process inherits most of its attributes, such as open files, from its parent process. In UNIX, a child process is in fact created (using
fork) as a copy of the parent. The child process can then overlay itself with a different program (using exec) as required.
Each process may create many child processes but will have at most one parent process; if a process does not have a parent this usually indicates that it was created directly by the kernel.
fork()is used to create processes. The purpose of
fork()is to create a new process, which becomes the child process of the caller.
An orphan process is a running process whose parent process has finished or terminated.
In a Unix-like operating system any orphaned process will be immediately adopted by the special
initsystem process. This operation is called re-parenting and occurs automatically.
Even though technically the orphan process has the
initprocess as its parent, it is still called an orphan process since the process that originally created it no longer exists.
A process can be orphaned unintentionally:
such as when the parent process terminates or crashes. The process group mechanism in most Unix-like operation systems can be used to help protect against accidental orphaning, where in coordination with the user’s shell will try to terminate all the child processes with the
SIGHUPprocess signal, rather than letting them continue to run as orphans.
A process may also be intentionally orphaned:
it becomes detached from the user’s session and left running in the background; usually to allow a long-running job to complete without further user attention, or to start an indefinitely running service.
A daemon process is an intintionally orphaned process in order to have a background process.
A daemon process is usually created by a process
forking a child process and then immediately exiting, thus causing
initto adopt the child process. In a Unix environment, the parent process of a daemon is often, but not always, the
In addition, a daemon or the operating system typically must perform other operations, such as dissociating the process from any controlling terminal (tty). Such procedures are often implemented in various convenience routines such as
nohupcommand is one means to accomplish this.
Typically daemon names end with the letter d: for example,
syslogdis the daemon that implements the system logging facility and
sshdis a daemon that services incoming SSH connections.
A zombie process (or defunct process) is a process that has completed execution but hasn’t been reaped by its parent process. As result it holds a process entry and the PID in the process table.
The term zombie process derives from the common definition of a movie zombie — an undead person. In the term’s metaphor, the child process has “died” but has not yet been “reaped”. Also, unlike normal processes, the kill command has no effect on a zombie process.
When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process’s entry in the process table remains. The parent can read the child’s exit status by executing the
waitsystem call, whereupon the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the
SIGCHLDsignal, which the parent receives whenever a child has died.
After the zombie is removed, its process identifier (PID) and entry in the process table can then be reused. However, if a parent fails to call
wait, the zombie will be left in the process table.
In some situations this may be desirable, for example if the parent creates another child process it ensures that it will not be allocated the same PID.
On modern UNIX-like systems (that comply with SUSv3 specification in this respect), the following special case applies: if the parent explicitly ignores
SIGCHLDby setting its handler to
SIG_IGN(rather than simply ignoring the signal by default) or has the
SA_NOCLDWAITflag set, all child exit status information will be discarded and no zombie processes will be left
A zombie process is not the same as an orphan process. An orphan process is a process that is still executing, but whose parent has died. They do not become zombie processes; instead, they are adopted by
init(process ID 1), which waits on its children.
A zombie process is similar to a “memory leak”: a loss of a system resource caused by failure to release previously reserved portion. A zombie process is usually a sign of invalid software behavior.
Process Identifier aka
The operating system kernel identifies each process by its numerical process identifier -
PPID stands for
The process 0 is a special process that is created when the system boots. After forking a child process (the Process 1), the Process 0 becomes the swapper process (sometimes also known as the “idle task”).
PID 1 aka
The process 1, known as
init, is the ancestor of every other process in the system.
In some systems, including UNIX based systems such as Linux, the very first process (called
init) is started by the kernel at booting time and never terminates (see Linux startup process); other parentless processes may be launched to carry out various daemon tasks in userspace.
Process 1 has unique responsibility: be indirect or direct parent process.
- adopting orphaned child processes
- reaping zombie process-es
- handling signals for child processes
process running as PID 1 inside a container is treated specially by Linux: it ignores any signal with the default action. So, the process will not terminate on SIGINT or SIGTERM unless it is coded to do so — https://docs.docker.com/engine/reference/run/#foreground
The process table is a registry of all running processes (or exited before being reaped) in the system. Each process is represented by an process entry.
A somewhat stripped one:
$ ps -axf -o pid,ppid,tty,stat,cmd
PID PPID TT STAT CMD
2 0 ? S [kthreadd]
4 2 ? I< \_ [kworker/0:0H]
8 2 ? I \_ [rcu_sched]
1 0 ? Ss /sbin/init
406 1 ? S<s /lib/systemd/systemd-journald
807 1 ? Ss /usr/sbin/cron -f
871 1 ? Ss /usr/sbin/sshd -D
1480 871 ? Ss \_ sshd: multipass [priv]
1560 1480 ? S \_ sshd: multipass@pts/0
1561 1560 pts/0 Ss \_ -bash
1813 1561 pts/0 R+ \_ ps -axf -o pid,ppid,tty,stat,cmd
872 1 tty1 Ss+ /sbin/agetty -o -p -- \u --noclear tty1 linux
Process State and state codes
The state codes: different values that the
state output specifiers (header
S) display to describe the state of a process:
- `D` uninterruptible sleep (usually IO)
- `R` running or runnable (on run queue)
- `S` interruptible sleep (waiting for an event to complete)
- `T` stopped by job control signal
- `t` stopped by debugger during the tracing
- `W` paging (not valid since the 2.6.xx kernel)
- `X` dead (should never be seen)
- `Z` defunct ("zombie") process, terminated but not reaped by its parent
For BSD formats and when the
stat keyword is used, additional characters may be displayed:
- `<` high-priority (not nice to other users)
- `N` low-priority (nice to other users)
- `L` has pages locked into memory (for real-time and custom IO)
- `s` is a session leader
- `l` is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
- `+` is in the foreground process group
- What’s advantage of Tini
- Choosing an init process for multi-process containers
- A way to kill a zombie without reboot?
- My process became PID 1 and now signals behave strangely
- Docker and the PID 1 zombie reaping problem
- Why is SIGINT not propagated to child process when sent to its parent process?
- Why you need an init system
- 10 best practices for creating good docker images