Orphan vs Zombie vs Daemon processes

gmarik 7 min

Process

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.

Parent Process

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:

Every process (except the very first one):

Child process

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.

System call fork() is used to create processes. The purpose of fork() is to create a new process, which becomes the child process of the caller.

Orphan Process

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 init system process. This operation is called re-parenting and occurs automatically.

Even though technically the orphan process has the init process as its parent, it is still called an orphan process since the process that originally created it no longer exists.

Unintentional Orphan

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 SIGHUP process signal, rather than letting them continue to run as orphans.

Intentional Orphan

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.

Daemon Process

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 init to adopt the child process. In a Unix environment, the parent process of a daemon is often, but not always, the init process.

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 daemon(3) in Unix.

The Unix nohup command is one means to accomplish this.

Typically daemon names end with the letter d: for example, syslogd is the daemon that implements the system logging facility and sshd is a daemon that services incoming SSH connections.

Zombie Process

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 in the process table and the PID.

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 wait system 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 SIGCHLD signal, 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 SIGCHLD by setting its handler to SIG_IGN (rather than simply ignoring the signal by default) or has the SA_NOCLDWAIT flag 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 PID

The operating system kernel identifies each process by its numerical process identifier. PPID stands for Parent PID

Process 0 aka PID 0

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”).

Process 1 aka PID 1 aka init

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.

This means:

  1. adopting orphaned child processes.
  2. reaping zombie processes.
  3. 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

Process Table

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.

Process table: example

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

Different values that the s, stat and state output specifiers (header STAT or S) display to describe the state of a process:

For BSD formats and when the stat keyword is used, additional characters may be displayed:

References

Read More
Large MySQL migrations with pt-online-schema-change
Recursive data structures with Rails
Comments
read or add one↓