Linux Processes — Deep Basics

We now go one level deeper into the Ubuntu server.

Previously:

Hardware
 ↓
Linux Kernel
 ↓
Processes
 ↓
Services
 ↓
Nginx / PHP-FPM / MySQL

Now we answer:

What exactly is a process, how does Linux run it, and what happens when many users access your website simultaneously?

1. Program vs Process

These two words are different.

Program

A program is stored code.

Example:

/usr/sbin/nginx

It exists on storage.

Process

When that program is executed:

nginx executable
      ↓
Linux loads it
      ↓
Process

The process exists in memory and is actively running.

So:

Program
=
stored instructions

Process
=
running instance of those instructions

2. Simple Example

When you run:

ls

Linux finds the ls program and executes it.

Conceptually:

ls program
   ↓
process created
   ↓
CPU executes instructions
   ↓
output
   ↓
process exits

Nginx is different because it normally remains running.

3. Long-Running Process

Nginx:

Start
 ↓
Keep running
 ↓
Wait for requests
 ↓
Process requests
 ↓
Continue running

Similarly:

MySQL
PHP-FPM
SSH

are normally long-running services.

4. PID

Every running process receives a:

Process ID

or:

PID

For example:

PID 1
PID 100
PID 245
PID 1842

Run:

ps aux

and you’ll see process IDs.

5. PID 1

On your Ubuntu system, PID 1 is normally:

systemd

Conceptually:

Kernel
  ↓
systemd
  ↓
services
  ↓
processes

PID 1 has a particularly important role in the userspace system.

6. Parent Process

Processes can have relationships.

A process can create another process.

Conceptually:

Parent
  │
  ├── Child
  ├── Child
  └── Child

The operating system maintains parent/child relationships.

7. PPID

A process also has a:

Parent Process ID

or:

PPID

You can inspect this with commands such as:

ps -ef

You’ll see both:

PID
PPID

8. Example

Conceptually:

systemd
 PID 1
   │
   ▼
nginx
 PID 1000
 PPID 1

Then Nginx may create workers:

nginx master
 PID 1000
   │
   ├── worker PID 1001
   ├── worker PID 1002
   └── worker PID 1003

The exact process model depends on Nginx configuration and startup environment.

9. Nginx Master and Workers

Nginx commonly uses:

Master process
      │
      ├── Worker
      ├── Worker
      ├── Worker
      └── Worker

The master handles management tasks.

Workers handle connections and requests.

10. Why Multiple Workers?

Suppose your server has multiple CPU cores.

You don’t necessarily want one process handling everything.

Multiple workers can handle connections concurrently.

Conceptually:

             Nginx
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
    Worker  Worker  Worker

11. Worker Processes

A worker can handle many connections depending on configuration and workload.

This is important:

One worker does not necessarily equal one visitor.

You could have:

4 workers
1000 connections

The workers can handle many connections using event-driven I/O.

12. Event-Driven Architecture

Nginx is designed around an event-driven model.

Instead of:

1 connection
 ↓
1 permanently occupied process

Nginx can efficiently manage many connections with a smaller number of worker processes.

Conceptually:

Worker
 │
 ├── Connection A
 ├── Connection B
 ├── Connection C
 ├── Connection D
 └── ...

This is one reason Nginx is efficient for handling large numbers of connections.

13. PHP-FPM Is Different

PHP-FPM commonly uses a pool of PHP worker processes.

Conceptually:

PHP-FPM
   │
   ├── PHP Worker 1
   ├── PHP Worker 2
   ├── PHP Worker 3
   └── PHP Worker 4

When Nginx needs PHP:

Nginx
 ↓
PHP-FPM
 ↓
available worker
 ↓
PHP execution

14. Why PHP Workers Matter

Suppose:

10 visitors

request dynamic WordPress pages simultaneously.

PHP-FPM needs enough worker capacity to process requests concurrently.

If all workers are busy:

Request
 ↓
PHP-FPM
 ↓
No available worker
 ↓
Wait

This can increase response time.

15. PHP-FPM Worker Pool

PHP-FPM can be configured with process-management modes such as:

static
dynamic
ondemand

These control how PHP worker processes are created and managed.

We will study these in detail later.

16. MySQL Process

MySQL is also a long-running service.

Conceptually:

systemd
   ↓
mysqld
   ↓
database engine

The MySQL server manages:

Connections
Queries
Memory
Tables
Indexes
Transactions
Storage

17. One WordPress Request

Now look at one request again:

Browser
 ↓
Nginx worker
 ↓
PHP-FPM worker
 ↓
WordPress
 ↓
MySQL

Several processes may participate in one request.

18. Many Requests

Suppose 20 users visit simultaneously:

                  Nginx
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    Worker 1     Worker 2     Worker 3
       │            │            │
       └────────────┼────────────┘
                    ▼
                 PHP-FPM
             ┌──────┼──────┐
             ▼      ▼      ▼
           PHP 1  PHP 2  PHP 3
                    │
                    ▼
                  MySQL

This is a simplified representation, but it shows the relationship.

19. CPU Scheduling

The CPU cannot literally execute an unlimited number of instructions simultaneously on one core.

Linux uses scheduling.

Conceptually:

Process A
Process B
Process C
Process D
      ↓
CPU scheduler
      ↓
CPU cores

The kernel decides which runnable tasks receive CPU time.

20. Context Switching

Suppose the CPU is executing:

Process A

and then switches to:

Process B

Linux saves/restores execution state.

This is called:

Context switching

Conceptually:

CPU
 ↓
Process A
 ↓
save state
 ↓
Process B
 ↓
execute

Context switching has overhead, so having huge numbers of processes is not automatically better.

21. Threads

A process can contain multiple:

Threads

Conceptually:

Process
 ├── Thread 1
 ├── Thread 2
 └── Thread 3

Threads share many resources within their process.

The exact relationship between Linux tasks, threads, and processes is more nuanced, but this model is useful initially.

22. Process vs Thread

Simplified:

Process
=
independent execution environment

Thread
=
execution path within a process

Threads within a process can share memory.

This makes communication efficient but also introduces synchronization challenges.

23. Nginx and Threads

Nginx’s common architecture is heavily based on processes and event-driven workers rather than creating one thread per connection.

This is different from some other server architectures.

24. PHP and Threads

PHP-FPM generally uses separate worker processes rather than requiring a large multithreaded PHP execution model.

Conceptually:

PHP-FPM
 ↓
multiple worker processes

This gives process isolation between workers.

25. Process States

Linux processes can have different states.

You may encounter:

R
S
D
T
Z

The exact state meanings can be inspected through tools such as ps.

26. `R` — Running/Runnable

R represents a process that is running or runnable.

Conceptually:

Process
 ↓
ready to execute

It may be actively executing or waiting to be scheduled.

27. `S` — Sleeping

A sleeping process is waiting for an event.

For example:

Nginx worker
 ↓
waiting for network activity

This is normal.

A sleeping process isn’t necessarily broken.

28. `D` — Uninterruptible Sleep

D commonly indicates waiting in an uninterruptible kernel wait, often associated with I/O.

For example:

Process
 ↓
waiting for storage/network-related kernel operation

A large number of persistent D processes can indicate an underlying problem.

29. `T` — Stopped/Traced

A process can be stopped or traced.

For example, debugging tools can stop processes.

30. `Z` — Zombie

A zombie process is a process that has finished execution but whose parent has not yet collected its exit status.

Conceptually:

Child
 ↓
finishes
 ↓
Zombie
 ↓
Parent collects status
 ↓
removed

A small number of transient zombies can be normal.

Persistent large numbers can indicate a parent-process management problem.

31. Zombie Does Not Mean Running

A zombie process is:

finished execution

It is not actively consuming CPU like a normal running process.

It mainly remains as a process-table entry until its parent handles it.

32. Inspect Process States

You can use:

ps -eo pid,ppid,user,stat,comm

This gives a useful view of:

PID
PPID
USER
STATE
COMMAND

33. Process Tree

Try:

pstree -p

if available.

You may see something conceptually like:

systemd(1)
 ├─sshd(...)
 ├─nginx(...)
 │ ├─nginx(...)
 │ └─nginx(...)
 ├─php-fpm(...)
 │ ├─php-fpm(...)
 │ └─php-fpm(...)
 └─mysqld(...)

This is very useful when learning server architecture.

34. CPU Usage

Use:

top

You’ll see processes and CPU usage.

Conceptually:

PID
USER
CPU%
MEM%
COMMAND

35. Memory Usage

top also helps identify processes consuming significant memory.

For example:

php-fpm
mysqld
nginx

may have very different memory footprints.

36. Why PHP Can Consume a Lot of RAM

A PHP worker may load:

WordPress core
Plugins
Theme
Libraries
Application data

into memory.

A complex WordPress request can therefore consume considerably more memory than a simple static file request.

37. Static vs Dynamic Resource Cost

Compare:

Static

GET /logo.png
 ↓
Nginx
 ↓
disk/cache
 ↓
response

Dynamic

GET /article/
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
Plugins
 ↓
MySQL
 ↓
Theme
 ↓
HTML

Dynamic requests generally involve more computation.

38. Why Caching Is Powerful

Suppose the result of:

GET /article/

is cached.

Instead of:

Nginx
 ↓
PHP
 ↓
WordPress
 ↓
MySQL

the request might become:

Nginx
 ↓
Cache
 ↓
Response

This can dramatically reduce application work.

39. CPU Bottleneck

If CPU becomes saturated:

CPU
 ↓
100%

requests may take longer.

Possible symptoms:

Slow website
Slow PHP
Slow MySQL
High load
Timeouts

But high CPU does not automatically identify the root cause.

40. Memory Bottleneck

If available memory becomes very low:

RAM
 ↓
pressure

Linux may use swap and/or processes may encounter allocation problems.

Performance can degrade substantially.

41. Swap

Swap is disk-backed space used by the operating system as part of its virtual memory system.

Conceptually:

RAM
 ↓
memory pressure
 ↓
some pages may be moved/reclaimed
 ↓
swap/storage

Swap is much slower than RAM.

It is not a replacement for sufficient RAM.

42. Why Your Server Needs Monitoring

A hosting server should be watched for:

CPU
RAM
Swap
Disk
Disk I/O
Network
Processes
Connections
PHP-FPM workers
MySQL load
Nginx errors

This becomes the foundation of server monitoring.

43. Process Limits

Linux can impose limits on resources such as:

Open files
Processes
Memory
CPU

You can inspect shell limits with:

ulimit -a

Some limits can affect high-traffic applications.

44. File Descriptors

A process may need file descriptors for:

Files
TCP sockets
Unix sockets
Pipes
Other I/O resources

A busy Nginx server can have many open sockets.

Therefore:

Traffic
 ↓
Connections
 ↓
Sockets
 ↓
File descriptors

can become a scaling consideration.

45. Nginx Connection Capacity

If Nginx is configured for a certain number of worker connections, that becomes part of its capacity planning.

The actual effective maximum is influenced by:

worker_processes
worker_connections
file descriptor limits
CPU
memory
network
application latency

So worker_connections is not simply “the number of users the server supports.”

46. PHP-FPM Capacity

PHP-FPM has another important constraint:

Maximum simultaneous PHP workers

Suppose you have:

10 PHP workers

and:

50 dynamic requests

The first group can be processed while others may wait, depending on queue/backlog behavior.

47. The Bottleneck Principle

A web application can be limited by:

DNS
Network
CPU
RAM
Disk I/O
Nginx
PHP-FPM
MySQL
External API

The slowest constrained component can become the bottleneck.

48. Example

Suppose:

CPU:       20%
RAM:       40%
Disk:      normal
Nginx:     normal
PHP-FPM:   100% workers busy
MySQL:     normal

The likely immediate bottleneck is:

PHP-FPM capacity

Increasing CPU alone may not solve the problem.

49. Another Example

Suppose:

CPU:       30%
RAM:       40%
PHP-FPM:   normal
MySQL:     very slow

Then the application can still be slow because:

WordPress
 ↓
MySQL query
 ↓
slow

The server doesn’t need more PHP workers to solve a database bottleneck.

50. Another Example

Suppose:

CPU: 100%
PHP-FPM: busy
MySQL: busy

The first question becomes:

Which process is consuming CPU?

Run:

top

Then investigate the process and workload.

51. Signals

Linux can communicate with processes using:

Signals

Examples include:

SIGTERM
SIGKILL
SIGHUP
SIGINT

These have different semantics.

52. SIGTERM

SIGTERM is generally a request to terminate gracefully.

Conceptually:

system/service manager
       ↓
SIGTERM
       ↓
process
       ↓
clean shutdown

It gives the application an opportunity to clean up.

53. SIGKILL

SIGKILL forcibly terminates a process.

It cannot be caught or handled by the target process.

This is why it should not be the first choice for normal service management.

Prefer graceful service management whenever possible.

54. SIGHUP

Historically associated with terminal hangups, but many Unix daemons use it for configuration reload behavior.

For example, some services interpret SIGHUP as:

Reload configuration

The exact behavior is application-specific.

55. Why `systemctl` Is Better Than Random Signals

Instead of manually killing Nginx processes:

systemctl reload nginx

or:

systemctl restart nginx

lets systemd and the service’s unit configuration manage the operation properly.

This is safer and more predictable.

56. Nginx Graceful Reload

Nginx is designed to support configuration reloads with minimal disruption.

Typical workflow:

Edit config
 ↓
nginx -t
 ↓
systemctl reload nginx

This is an excellent production habit.

57. Process Monitoring

Useful commands:

ps aux

top

pstree -p

systemctl status nginx

systemctl status mysql

58. Find Nginx Processes

You can use:

ps aux | grep nginx

But remember that grep nginx itself can appear in the results.

A cleaner approach is often:

pgrep -a nginx

59. Find PHP-FPM

Depending on your PHP version:

pgrep -a php-fpm

or:

ps aux | grep php-fpm

60. Find MySQL

pgrep -a mysqld

Again, the exact process name can vary by installation.

61. A Real Request and Processes

Let’s put the entire lesson together.

User requests:

GET /

Then:

Nginx worker
   ↓
PHP-FPM worker
   ↓
WordPress
   ↓
MySQL

The kernel manages:

CPU
RAM
Sockets
Files
Scheduling

while systemd manages the long-running services.

62. Complete Linux Stack

                         USER
                           │
                           ▼
                        BROWSER
                           │
                           ▼
                         HTTP
                           │
                           ▼
                         NGINX
                           │
                     ┌─────┴─────┐
                     ▼           ▼
                Static files   PHP-FPM
                                  │
                                  ▼
                              WordPress
                                  │
                           ┌──────┴──────┐
                           ▼             ▼
                      Filesystem       MySQL
                           │             │
                           └──────┬──────┘
                                  ▼
                              RESPONSE
                                  │
                                  ▼
                                NGINX
                                  │
                                  ▼
                                NETWORK
                                  │
                                  ▼
                              LINUX KERNEL
                           ┌──────┼──────┐
                           ▼      ▼      ▼
                          CPU    RAM   Storage

63. The Most Important Concepts Today

Remember these distinctions:

Program
=
stored code

Process
=
running program

PID
=
process identifier

PPID
=
parent process identifier

Thread
=
execution path inside a process

Socket
=
communication endpoint

File descriptor
=
process handle for I/O resources

Service
=
managed long-running system component

systemd
=
service/process management framework

64. How This Helps Your Hosting Platform

When you eventually create a hosting dashboard, you could expose information such as:

Server Status
─────────────
CPU        22%
RAM        48%
Disk       37%
Nginx      Running
PHP-FPM    Running
MySQL      Running
SSL        Valid

Behind that simple dashboard are Linux commands and service APIs.

For example:

Dashboard
   ↓
Monitoring logic
   ↓
Linux/systemd
   ↓
Processes
   ↓
Metrics

65. The Next Layer: Virtual Memory

We have discussed:

CPU
RAM
Processes
Threads

but we haven’t yet explained something fundamental:

How can dozens or hundreds of processes each behave as if they have their own memory?

The answer is:

Virtual Memory

The next lesson will go deep into:

Physical RAM
 ↓
Virtual address
 ↓
Process address space
 ↓
Pages
 ↓
Page tables
 ↓
MMU
 ↓
TLB
 ↓
Physical memory
 ↓
Swap

Then we will connect it to:

Nginx memory
PHP-FPM memory
MySQL memory
WordPress memory

and understand why a VPS with 4 GB RAM can run many thousands of processes without each process directly owning a fixed physical section of RAM.

CresignSys Learn — Lesson 032

Linux Processes — Deep Basics

1. Program vs Process

Program

Process

2. Simple Example

3. Long-Running Process

4. PID

Process ID

PID

5. PID 1

6. Parent Process

7. PPID

Parent Process ID

PPID

8. Example

9. Nginx Master and Workers

10. Why Multiple Workers?

11. Worker Processes

12. Event-Driven Architecture

13. PHP-FPM Is Different

14. Why PHP Workers Matter

15. PHP-FPM Worker Pool

16. MySQL Process

17. One WordPress Request

18. Many Requests

19. CPU Scheduling

20. Context Switching

Context switching

21. Threads

Threads

22. Process vs Thread

23. Nginx and Threads

24. PHP and Threads

25. Process States

26. R — Running/Runnable

27. S — Sleeping

28. D — Uninterruptible Sleep

29. T — Stopped/Traced

30. Z — Zombie

31. Zombie Does Not Mean Running

32. Inspect Process States

33. Process Tree

34. CPU Usage

35. Memory Usage

36. Why PHP Can Consume a Lot of RAM

37. Static vs Dynamic Resource Cost

Static

Dynamic

38. Why Caching Is Powerful

39. CPU Bottleneck

40. Memory Bottleneck

41. Swap

42. Why Your Server Needs Monitoring

43. Process Limits

44. File Descriptors

45. Nginx Connection Capacity

46. PHP-FPM Capacity

47. The Bottleneck Principle

48. Example

49. Another Example

50. Another Example

51. Signals

Signals

52. SIGTERM

53. SIGKILL

54. SIGHUP

55. Why systemctl Is Better Than Random Signals

56. Nginx Graceful Reload

57. Process Monitoring

58. Find Nginx Processes

59. Find PHP-FPM

60. Find MySQL

61. A Real Request and Processes

62. Complete Linux Stack

63. The Most Important Concepts Today

64. How This Helps Your Hosting Platform

65. The Next Layer: Virtual Memory

Virtual Memory

Comments

26. `R` — Running/Runnable

27. `S` — Sleeping

28. `D` — Uninterruptible Sleep

29. `T` — Stopped/Traced

30. `Z` — Zombie

55. Why `systemctl` Is Better Than Random Signals