2.6 Working with Processes

Introduction

Processes are the running programs on your Linux system. Any time you open a web browser, run a command in the terminal, or start a background service, Linux creates one or more processes. Understanding processes is essential for diagnosing slow systems, stopping misbehaving programs, and managing what is running on your machine.

This chapter introduces the general ideas that apply to processes in Linux. The specific commands for viewing processes, killing them, working with foreground and background jobs, and managing system services are covered in their own sections later in this part of the course. Here, you will learn what a process is, how Linux identifies processes, and what kinds of information and states a process can have.

What Is a Process in Linux?

A process is an instance of a program that is currently executing. The program itself is just data stored on disk in an executable file. When you run the program, the kernel loads it into memory, sets up the resources it needs, and turns it into a process.

Every process has its own memory space, certain permissions, and a set of resources such as open files or network connections. The kernel keeps track of all processes and decides when each one is allowed to use the CPU.

Some typical examples of processes include your terminal emulator, the shell that runs inside the terminal, your file manager, a web browser, or a web server on a remote machine. Even many small commands such as ls or cat are processes while they run.

Process Identification and the PID

Linux identifies every process with a Process ID, shortened to PID. The PID is a number that is unique among all currently running processes. When a process exits, its PID can later be reused by another process, but at any moment two processes on the same system cannot share the same PID.

The kernel starts a process, assigns it a PID, and then stores information about it in internal tables. Many tools you will learn later use the PID to refer to and control processes. For example, when you terminate a process manually, you usually refer to it by PID.

You can think of the PID as a label that lets the kernel and userspace tools talk about a specific running instance. When the process ends, that label no longer points to anything.

Parent and Child Processes

In Linux, almost every process is created by another process. The existing process calls into the kernel to create a new process, which becomes its child. The original process is then known as the parent. This creates a tree of processes that ultimately traces back to an initial process that the kernel starts during boot.

When you run a command in a shell, the shell starts a new process for that command and becomes its parent. For instance, if you run ls, your shell process will call the kernel to start a child process that runs the ls program. When ls finishes, the child process exits and the shell can accept a new command.

Each process knows the PID of its parent, which is called the PPID. Tools for viewing processes show both PID and PPID. This parent child relationship is important for understanding how processes are organized and how they can be managed as groups.

Process States

A process is not always using the CPU. Sometimes it is actively running, sometimes it is paused waiting for input, and sometimes it has finished but is not yet completely cleaned up. Linux uses process states to describe what a process is doing at any time.

The most common high level states include running, sleeping, stopped, and zombie. A running process is either currently executing on a CPU or is ready to execute as soon as the scheduler selects it. A sleeping process is waiting for some event such as input from the user, data from disk, or a network reply. A stopped process has been paused, often by a signal.

A zombie process is a special case. It is a process that has finished executing but whose parent has not yet collected its exit status. The kernel keeps a minimal record of it so the parent can read how it exited. Zombies do not consume CPU or real memory, but a large number of them can indicate that some parent process is not behaving correctly.

Process viewers show these states with short codes. You will see how to read those codes when working with the tools that display processes.

How Linux Schedules Processes

Your system usually has far more processes than CPU cores. Linux uses a scheduler inside the kernel to share CPU time among them. The scheduler quickly switches between processes so that it appears as if many processes are running at the same time, even on a single core.

Each process has a priority that influences how often and how long it is allowed to run. There are different scheduling classes, such as normal and real time, and within these classes the priority affects scheduling decisions. For most desktop and server use, Linux handles scheduling automatically and you do not need to change priorities.

The scheduler aims to keep interactive applications responsive while still allowing background tasks to make progress. When the kernel decides a process should be paused, it saves its state and later restores it when the process is scheduled again. From the point of view of the process, it continues as if nothing happened.

Users, Permissions, and Processes

Every process runs as some user, often with specific group memberships. The user ID and group ID associated with a process determine what files it can open, what network ports it can bind to, and what operations are allowed. For example, normal user processes generally cannot modify system files that belong to the root user.

When you start a program from your shell, the process inherits your user identity and your environment. This includes environment variables and the current working directory. Some programs can temporarily change their active identity if they have special permissions, but the basic idea remains that permissions protect the system from untrusted or buggy programs.

System services and daemons that need broad access often run as dedicated service users or as root. To perform administrative actions from a shell, you typically run commands with elevated privileges, which starts new processes with more powerful permissions. The specifics of how to do this safely are covered where sudo and system services are discussed.

Process Resources

The kernel tracks the resources that each process uses. These resources include CPU time, memory, open files, network connections, and more. Each process has its own virtual memory space so that programs cannot directly read or write the memory of others. This separation increases stability and security.

Linux also supports limits on process resources. For example, there can be a maximum number of files a process is allowed to open or a ceiling on how much memory it can allocate. These limits help prevent a single runaway process from consuming all resources and causing the system to become unresponsive.

From the user perspective, you will observe resource usage through monitoring tools that show CPU percentage, memory usage, and other metrics for each process. In later chapters on system monitoring, you will learn how to interpret those metrics in more detail.

Environment and Inheritance

When a new process is created, it inherits several properties from its parent process. One important property is the environment, which consists of environment variables that store configuration values in key value format. Another property is the current working directory, which is the directory where relative paths are resolved.

This inheritance means that the context from your shell carries over into programs you start. If you change an environment variable in your shell, then run a command, the new process sees that updated environment variable. Changes made inside the child process do not flow back into the parent process.

Processes also inherit file descriptors from their parents. For terminal commands, this usually means standard input, standard output, and standard error. Later, when you learn about input and output redirection, you will see how these inherited descriptors are used to connect processes together in pipelines.

Signals and Process Control

Linux uses signals as a basic mechanism to communicate with processes. A signal is a small notification sent to a process that tells it something happened, such as a request to terminate or an instruction to stop temporarily. The process can react to a signal by exiting, cleaning up, or ignoring it, depending on the signal type and how the program is written.

For interactive use, the most visible signals are those triggered by keyboard shortcuts in the terminal. For example, a specific key combination usually sends an interrupt signal that asks the foreground process to stop. Another combination stops the process but keeps it in memory so that it can be resumed.

There are also signals that tell a process to reload its configuration, to pause, or to terminate immediately. Tools for killing processes send these signals systemwide, not just from the terminal. The detailed use of these tools and signal types will be covered where process control commands are explained.

Foreground, Background, and Daemons

Processes that run in a terminal can be in the foreground or in the background. A foreground process is directly attached to the terminal, and it receives keyboard input and prints output there. While a long running command occupies the foreground, your shell waits for it to finish before accepting new input.

Background processes are still running, but they are not actively using the terminal for input. Starting or moving a process into the background lets you keep working in the same terminal. Job control features in shells help you manage this, and their use is discussed in the chapter on foreground and background jobs.

Daemons are long running background processes that do not usually have a terminal at all. They often start during boot and provide services such as web serving, logging, or scheduling tasks. On modern Linux systems, daemons are typically managed by an init system such as systemd, which controls their lifecycle.

System Services and Process Management

On a modern Linux distribution, many important processes are system services. These are daemons managed by a central service manager that starts them, stops them, restarts them if they crash, and keeps track of their status. For example, your networking service, display manager, and logging service are all processes under this system manager.

From the point of view of the kernel, services are still just processes, but they are started and controlled in a structured way. Instead of running them manually from a terminal, you use management commands that talk to the service manager. This makes sure dependencies are handled and that services restart correctly when needed.

Administrative tools for services provide information such as whether a service is active, when it started, and why it stopped. You will learn to use these tools in later chapters about systemd and service management, where you will see how process concepts apply to real system services.

Why Processes Matter to Everyday Use

Even for a beginner, understanding processes improves day to day work on Linux. When an application freezes, knowing that it is just a process lets you find it and stop it safely. If your computer feels slow, you can look at which processes are using the most CPU or memory and decide how to respond.

As you progress, you will interact with processes constantly, whether you are running commands, writing scripts, or managing servers. Every tool that shows system activity is, at its core, showing you information about processes. With the foundation from this chapter, you are ready to learn the specific commands that let you view, control, and manage them in detail.