Processes and inter-process communication

This chapter follows Hardware and devices in Linux.

Every running program is a process with a PID, credentials, file descriptors, and memory mappings. Shell pipelines, web servers forking workers, and desktop buses all rely on the same kernel primitives: fork, exec, signals, and IPC channels. This page is the OS view; Shellscripting with Bash covers scripting those primitives, and Code Execution Boundaries in Node.js compares in-process versus out-of-process work in application design.

fork, exec, and the process tree

fork duplicates the calling process; the child gets a new PID and copy-on-write memory. exec replaces the child’s program image while keeping the PID—how /bin/bash becomes /usr/bin/python3 after you type a command.

PID 1 (systemd) starts services; each session may have a shell as session leader. ps -ejH or pstree visualize the tree:

1
ps aux
2
pstree -p $$

Zombie processes appear as <defunct> until the parent reaps them; orphan children reparent to PID 1.

Process states and signals

Processes move among running, sleeping, stopped, and zombie states. kill -l lists signals; SIGTERM asks politely to exit, SIGKILL stops immediately without cleanup.

1
kill -TERM 1234
2
kill -9 1234

Job control in interactive shells sends SIGTSTP (Ctrl+Z) and SIGCONT. Daemons often ignore hangup (SIGHUP) or reload on it—Apache’s graceful behavior is an application policy on top of signals.

Return codes 0–255 propagate to the shell as $?—see the return codes section in the Bash article for scripting patterns.

Pipes, FIFOs, and standard streams

A pipe connects stdout of one process to stdin of another without a disk file. Shells build pipelines (cmd1 | cmd2); the kernel holds the buffer.

FIFOs (named pipes) are filesystem paths with mkfifo. Standard streams (0, 1, 2) are inherited across fork; redirection is shell syntax, but the underlying fds are OS objects.

For JSON over pipes in scripts, Mastering JSON in Bash stays in user space—still the same fd machinery.

Unix domain sockets and network sockets

Unix domain sockets (AF_UNIX) communicate on one host with lower overhead than TCP loopback. Used by databases, Docker, and D-Bus.

Network sockets (AF_INET, AF_INET6) are the Linux side of TCP/UDP; protocol semantics live in Networking concepts and protocols, while Networking on Linux covers interfaces and nftables.

1
ss -xl | head
2
ss -tlnp

Shared memory and message queues

POSIX shared memory (shm_open, mmap) lets cooperating processes share pages. Message queues (mq_open) pass structured messages with kernel persistence options.

These are lower level than D-Bus; most desktop and service integration prefers D-Bus or sockets unless you need raw performance.

D-Bus on Linux desktops and services

D-Bus is a message bus for activation, settings, and hardware events. Session bus for the logged-in user; system bus for system-wide services. busctl and dbus-send introspect; desktop environments rely on D-Bus for settings daemons and polkit prompts.

systemd exposes many operations on the system bus; container and VM tooling often still uses plain sockets and signals for portability.

Package installation and permissions build on processes running as specific users—next: Package management on Debian.

The next chapter is Package management on Debian.