Linux Processes — From Program to Running Service

We now move one layer deeper into Ubuntu.

You have learned:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

But what is Nginx actually doing inside Linux?

It is a process.

The same is true for:

mysqld
php-fpm
sshd
cron
certbot

1. Program vs Process

These two words are often confused.

Program

A program is software stored on disk.

Example:

/usr/sbin/nginx

Process

A process is a running instance of a program.

Conceptually:

Program on disk
      ↓
    execute
      ↓
Process in RAM

2. Simple Example

You have:

nginx

installed on the server.

That means the program exists.

But it doesn’t necessarily mean Nginx is running.

You can have:

Installed ✓
Running ✗

3. Running Program

When Linux starts Nginx:

nginx program
      ↓
loaded into memory
      ↓
process
      ↓
CPU executes instructions

Now Nginx is running.

4. PID

Every Linux process has a:

PID

Process ID.

Example:

nginx
PID 1234

The PID identifies that running process.

5. Find Processes

Use:

ps aux

This displays processes currently running.

You can search:

ps aux | grep nginx

6. `top`

Another important command:

top

It provides a continuously updating view of processes and resource usage.

You can see:

PID
CPU
RAM
process

7. `htop`

If installed:

htop

provides a more interactive process viewer.

8. Process Hierarchy

Linux processes can have parent/child relationships.

Conceptually:

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

9. PID 1

On modern Ubuntu systems:

PID 1

is normally:

systemd

You can verify:

ps -p 1 -f

You may see something like:

/usr/lib/systemd/systemd

10. Why PID 1 Matters

systemd is responsible for managing much of the system’s startup and services.

Conceptually:

Linux boot
    ↓
systemd
    ↓
services

11. systemd Starts Services

For example:

systemd
   │
   ├── nginx
   ├── mysql
   ├── ssh
   └── php-fpm

This is why you can use:

systemctl

to manage services.

12. `systemctl`

For Nginx:

sudo systemctl status nginx

For MySQL:

sudo systemctl status mysql

For PHP-FPM:

sudo systemctl status php8.3-fpm

The exact PHP version depends on your installation.

13. Service vs Process

These are not identical concepts.

service

is an operational unit managed by the service manager.

process

is a running execution instance.

Conceptually:

systemd service
      ↓
starts
      ↓
process

14. Installed

Suppose Nginx is installed.

You might have:

/usr/sbin/nginx

But:

systemctl status nginx

could show it isn’t running.

Therefore:

Installed
≠
Running

15. Enabled

Another confusing word is:

enabled

If you run:

sudo systemctl enable nginx

you are configuring Nginx to start automatically during appropriate system boot.

This does not necessarily mean:

Nginx is currently running

16. Started

To start it now:

sudo systemctl start nginx

So:

enable
=
start automatically at boot

start
=
start now

17. Restart

sudo systemctl restart nginx

This stops and starts the service.

Use it when you actually need a restart.

18. Reload

sudo systemctl reload nginx

A reload asks Nginx to reload configuration while trying to preserve existing service availability.

For configuration changes, reload is often preferable to a full restart when supported.

19. Restart vs Reload

Restart

stop
 ↓
start

Reload

running Nginx
 ↓
read new configuration
 ↓
continue serving

The exact behavior depends on the service.

20. Nginx Example

Suppose you modify:

/etc/nginx/sites-enabled/example.com

First:

sudo nginx -t

If successful:

sudo systemctl reload nginx

This is safer than blindly restarting after every configuration change.

21. Why `nginx -t`?

It tests Nginx configuration syntax and related configuration validity.

If there is an error:

nginx -t

can identify it before you reload.

22. Very Important Workflow

Use:

Edit
 ↓
nginx -t
 ↓
If successful
 ↓
reload
 ↓
test website

Not:

Edit
 ↓
restart
 ↓
hope

23. Process Command

You can inspect a process:

ps -p PID -f

For example:

ps -p 1234 -f

24. Find Nginx PID

pgrep nginx

or:

pidof nginx

25. Process Tree

A very useful command:

pstree

or:

pstree -p

This shows process relationships.

26. Why Process Trees Matter

You might see:

systemd
 ├─sshd
 ├─nginx
 │   ├─nginx
 │   └─nginx
 ├─php-fpm
 │   ├─php-fpm
 │   └─php-fpm
 └─mysqld

This gives you a conceptual picture of the running server.

27. Nginx Master and Worker Processes

Nginx commonly uses a master/worker architecture.

Conceptually:

nginx master
     │
     ├── worker
     ├── worker
     └── worker

The master handles management responsibilities.

Workers handle client connections and requests.

28. Why Multiple Workers?

A web server needs to handle many simultaneous connections.

Instead of one process doing everything:

one process
 ↓
many connections

Nginx can distribute work across worker processes.

29. PHP-FPM

PHP-FPM also uses multiple processes.

Conceptually:

php-fpm master
      │
      ├── PHP worker
      ├── PHP worker
      ├── PHP worker
      └── PHP worker

These workers execute PHP requests.

30. WordPress Request

Suppose:

GET /about/

requires PHP.

The flow can look like:

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

31. PHP-FPM Worker

A PHP-FPM worker may execute:

index.php

Then WordPress loads:

wp-config.php
WordPress core
theme
plugins

and eventually talks to MySQL.

32. MySQL Process

MySQL normally has a main server process, commonly named:

mysqld

You can inspect it:

ps aux | grep mysqld

33. SSH Process

When you connect using SSH:

ssh user@server

the server’s SSH service is typically:

sshd

There may be multiple processes/threads associated with active SSH sessions.

34. Cron

Linux also runs scheduled jobs.

On modern Ubuntu, scheduled tasks can be managed through several mechanisms, including:

cron
systemd timers

For example, automated maintenance might run periodically.

35. Certbot / ACME

Your SSL renewal process might use an ACME client such as Certbot.

It may run:

periodically
 ↓
check certificates
 ↓
renew when needed

The exact mechanism depends on how you installed/configured it.

36. Process Memory

Every process needs memory.

Conceptually:

RAM
│
├── Nginx
├── PHP-FPM
├── MySQL
├── SSH
├── systemd
└── other processes

37. Why PHP-FPM Can Consume Lots of RAM

Suppose you have:

20 PHP workers

Each worker can consume memory.

Conceptually:

20 workers
 ×
memory per worker
 =
significant RAM usage

The actual memory footprint varies by application and workload.

38. Too Many Workers

Suppose the server has:

4 GB RAM

and you configure too many PHP workers.

You could reach:

RAM exhaustion
 ↓
swap
 ↓
slow server

or potentially:

OOM
 ↓
process killed

39. Process CPU

Processes also consume CPU.

You might see:

mysqld
CPU 80%

or:

php-fpm
CPU 90%

This helps identify where processing time is going.

40. CPU Percentage Can Be Misunderstood

On a multi-core system, CPU percentages reported by tools can sometimes exceed 100% for a process using multiple cores.

For example:

4 cores

can produce an aggregate process usage around:

400%

depending on the tool’s measurement convention.

41. Load Average

Linux also has:

Load Average

Check with:

uptime

or:

top

You may see:

load average: 1.20, 0.80, 0.60

These correspond roughly to:

1 minute
5 minutes
15 minutes

42. What Does Load Mean?

Load average is not simply CPU percentage.

It reflects the number of tasks that are runnable or waiting in certain uninterruptible states.

So it can reflect:

CPU pressure
+
some I/O-related waiting

43. Example

Suppose:

2 CPU cores

and load average:

2.0

That could indicate approximately full utilization of CPU capacity under certain workloads.

But interpretation requires looking at CPU and I/O metrics too.

44. High Load ≠ Automatically Bad

Suppose:

8 cores
load = 4

That may be perfectly acceptable.

But:

2 cores
load = 15

is more concerning.

Always consider CPU count and whether tasks are blocked on I/O.

45. CPU Count

Check:

nproc

Example:

means Linux reports four available processing units.

46. Process States

Processes can have states such as:

R
S
D
T
Z

The most important beginner concepts:

R
=
running/runnable

S
=
sleeping

D
=
uninterruptible sleep, often waiting on I/O

Z
=
zombie

47. Zombie Process

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

Conceptually:

Child
 ↓
finished
 ↓
zombie entry

It is not actively consuming CPU like a running process.

48. Why Zombies Exist

The parent process needs to retrieve the child’s termination status.

This is called:

Reaping

Normally, well-behaved process managers handle this.

49. Don’t Panic About One Zombie

A single transient zombie isn’t necessarily a serious problem.

Many persistent zombies may indicate a parent-process bug or management issue.

50. Killing a Process

Linux provides:

kill PID

This sends a signal to the process.

For example:

kill 1234

The default signal is generally:

SIGTERM

51. SIGTERM

SIGTERM means approximately:

Please terminate gracefully.

A process can handle this signal and clean up resources.

This is preferable to immediately forcing termination.

52. SIGKILL

You can use:

kill -9 PID

This sends:

SIGKILL

The process cannot catch or gracefully handle SIGKILL.

Use it carefully.

53. Why `kill -9` Is Not the First Choice

Suppose:

Nginx

is stuck.

You could:

kill -9

but graceful termination is generally preferable.

Use:

SIGTERM

first when appropriate.

54. Service Restart Is Usually Better

If Nginx is managed by systemd:

sudo systemctl restart nginx

is generally preferable to manually killing its processes.

systemd understands the service lifecycle.

55. Parent Process

Suppose:

PID 100

starts:

PID 200

Then:

PPID of 200 = 100

PPID means:

Parent Process ID

56. View Parent Process

ps -o pid,ppid,cmd -p PID

For example:

ps -o pid,ppid,cmd -p 200

57. Why Parent/Child Matters

If you see:

php-fpm master
    ↓
PHP workers

you can understand why killing one worker may not permanently solve the problem.

The master may create another worker.

58. Process Lifecycle

A simplified process lifecycle:

Created
   ↓
Running
   ↓
Sleeping / Waiting
   ↓
Running
   ↓
Exit

The operating system manages these transitions.

59. File Descriptors

Processes interact with files, sockets, pipes, and other resources using:

File Descriptors

Examples:

0 = stdin
1 = stdout
2 = stderr

Network sockets are also represented through file descriptors.

60. Why This Matters

Nginx may have many open:

file descriptors

for:

client sockets
log files
configuration files
upstream connections

61. File Descriptor Limits

A server can have limits on how many file descriptors a process can use.

A high-traffic web server needs appropriate limits.

You can inspect shell limits with:

ulimit -n

The actual service limits may be configured differently through systemd or other mechanisms.

62. Nginx and Many Connections

Suppose:

10,000 clients

are connected.

Nginx needs enough:

file descriptors

and system resources to handle those connections.

This is one reason scalable hosting requires more than just CPU and RAM.

63. Process Scheduling

Linux has a scheduler.

The scheduler decides which runnable tasks get CPU time.

Conceptually:

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

64. CPU Time

Processes share CPU resources.

For example:

Nginx
PHP
MySQL
SSH
system tasks

all compete for CPU time.

The Linux scheduler manages this.

65. Nice Value

Linux has a concept called:

Nice

It influences process scheduling priority.

A process with a higher nice value generally receives lower scheduling preference relative to processes with lower nice values.

You can inspect process priorities with tools such as:

ps

66. Don’t Tune Nice Randomly

As a hosting administrator, don’t change process priorities without understanding the workload.

Most services should run with normal scheduling priority.

67. systemd Service States

When you run:

systemctl status nginx

you might see:

active (running)

This is the state you generally want for a continuously running web server.

68. Other Important States

You may see:

active
inactive
failed
activating
deactivating

69. `failed`

If you see:

Active: failed

something prevented the service from operating successfully.

Immediately inspect:

sudo journalctl -u nginx

or:

sudo journalctl -u nginx -n 100

70. Journal

Ubuntu’s systemd journal stores logs from many services.

Query:

journalctl

For Nginx:

sudo journalctl -u nginx

For MySQL:

sudo journalctl -u mysql

71. Follow Logs

To watch new log entries:

sudo journalctl -u nginx -f

The:

-f

means follow.

72. Why Logs Matter

A process saying:

failed

doesn’t tell you why.

The logs often provide the reason.

For example:

configuration error
permission denied
port already in use
missing file
resource exhaustion

73. Port Already in Use

Suppose you start a service and see:

Address already in use

This usually means another process already owns the port.

Check:

sudo ss -ltnp

For example:

:80

might already be occupied by Nginx.

74. Two Services Cannot Normally Listen on the Same IP/Port

For example:

Nginx → 0.0.0.0:80
Apache → 0.0.0.0:80

They cannot both normally bind the exact same address/port combination.

One will fail unless special socket-sharing arrangements are used.

75. This Explains Apache/Nginx Conflicts

If Apache is already listening on:

and you try to start Nginx on:

Nginx may fail.

Check:

sudo ss -ltnp | grep ':80'

76. Your Server

You previously worked with:

Apache
MySQL
Nginx
PHP-FPM

Understanding processes helps you determine which software is actually serving traffic.

Don’t assume the installed software is the active software.

77. Example Diagnostic

Website isn’t working.

Run:

sudo ss -ltnp | grep ':80'

If you see:

apache2

instead of:

nginx

then Apache is currently handling port 80.

That immediately changes your diagnosis.

78. Another Example

You expect PHP 8.3:

systemctl status php8.3-fpm

but Nginx configuration points to:

php8.2-fpm.sock

Then:

Nginx
 ↓
wrong PHP-FPM socket
 ↓
502

Process/service knowledge helps you detect this.

79. Unix Socket

PHP-FPM commonly uses a Unix socket such as:

/run/php/php8.3-fpm.sock

This is not a TCP port.

It is a local IPC endpoint.

80. IPC

IPC means:

Inter-Process Communication

Processes need ways to communicate.

Common mechanisms include:

Unix sockets
TCP sockets
pipes
signals
shared memory

81. Nginx → PHP-FPM

In your hosting setup, it may look like:

Nginx
 ↓
Unix socket
 ↓
PHP-FPM

rather than:

Nginx
 ↓
TCP Internet connection
 ↓
PHP-FPM

The first is local communication.

82. PHP-FPM → MySQL

PHP may then communicate with MySQL using:

Unix socket

or:

TCP

depending on the configuration.

For a local MySQL installation, a Unix socket is common.

83. Complete Process-Level Flow

Now combine everything:

Browser
 ↓
Internet
 ↓
Nginx worker process
 ↓
PHP-FPM worker process
 ↓
WordPress PHP
 ↓
MySQL server process
 ↓
InnoDB
 ↓
Disk

This is the actual running-process view of your hosting stack.

84. Process vs Service vs Port

These three must not be confused.

Process

mysqld PID 1234

Service

mysql.service

Port

They are related but different.

85. Example

MySQL could be:

Installed ✓
Service exists ✓
Process running ✓
Port 3306 listening ✗

This can happen if MySQL is configured to use a Unix socket or another port.

Therefore:

Running does not automatically mean “listening on 3306.”

86. The Same for Nginx

You could have:

Nginx process ✓

but:

port 443 ✗

if the configuration only listens on port 80.

87. The Diagnostic Model

When a service doesn’t work, ask:

Is the program installed?
        ↓
Does the systemd service exist?
        ↓
Is the service active?
        ↓
Is the process running?
        ↓
Is it listening on the expected socket/port?
        ↓
Is the firewall allowing it?
        ↓
Does the application respond?

This is a professional troubleshooting sequence.

88. Essential Commands

Processes

ps aux

Search process

ps aux | grep nginx

Process tree

pstree -p

Live process monitoring

top

Interactive monitoring

htop

Process IDs

pgrep nginx

Listening ports

sudo ss -ltnp

Service status

systemctl status nginx

Service logs

sudo journalctl -u nginx

Follow service logs

sudo journalctl -u nginx -f

89. One Command Set to Memorize

For Nginx:

sudo systemctl status nginx

sudo nginx -t

sudo ss -ltnp | grep ':80'

sudo ss -ltnp | grep ':443'

sudo journalctl -u nginx -n 100

This five-command sequence can solve many basic Nginx problems.

90. Your Hosting Platform Now Has Another Layer

You previously saw:

Network
 ↓
Nginx
 ↓
PHP-FPM
 ↓
MySQL

Now expand it:

Linux Kernel
      ↓
systemd
      ↓
services
      ↓
processes
      ↓
threads
      ↓
CPU/RAM

91. Complete Infrastructure Model

                         INTERNET
                            │
                            ▼
                           DNS
                            │
                            ▼
                         IP/TCP
                            │
                            ▼
                           TLS
                            │
                            ▼
                          NGINX
                       processes
                            │
                            ▼
                        PHP-FPM
                       processes
                            │
                            ▼
                       WORDPRESS
                            │
                            ▼
                         MYSQL
                       processes
                            │
                            ▼
                         INNODB
                            │
                            ▼
                          DISK

          All running under:

                    LINUX KERNEL
                         │
                         ▼
                       SYSTEMD

92. Most Important Concept of This Lesson

A server is not just:

files + configuration

A running server is:

software
+
processes
+
memory
+
CPU
+
network sockets
+
files
+
permissions
+
services

93. Next Lesson — 052

Linux Memory From the Absolute Basics

We will go underneath the processes and learn:

RAM
 ↓
Virtual Memory
 ↓
Pages
 ↓
Physical Memory
 ↓
Heap
 ↓
Stack
 ↓
Shared Memory
 ↓
Cache
 ↓
Buffer
 ↓
Swap
 ↓
OOM Killer

Then we’ll connect it directly to your hosting server:

Nginx
+
PHP-FPM workers
+
MySQL
+
Ubuntu
+
multiple WordPress websites

and learn how to calculate whether your VPS has enough RAM for the number of websites you want to host.

CresignSys Learn — Lesson 051

Linux Processes — From Program to Running Service

1. Program vs Process

Program

Process

2. Simple Example

3. Running Program

4. PID

PID

5. Find Processes

6. top

7. htop

8. Process Hierarchy

9. PID 1

systemd

10. Why PID 1 Matters

11. systemd Starts Services

12. systemctl

13. Service vs Process

14. Installed

15. Enabled

enabled

16. Started

17. Restart

18. Reload

19. Restart vs Reload

Restart

Reload

20. Nginx Example

21. Why nginx -t?

22. Very Important Workflow

23. Process Command

24. Find Nginx PID

25. Process Tree

26. Why Process Trees Matter

27. Nginx Master and Worker Processes

28. Why Multiple Workers?

29. PHP-FPM

30. WordPress Request

31. PHP-FPM Worker

32. MySQL Process

33. SSH Process

34. Cron

35. Certbot / ACME

36. Process Memory

37. Why PHP-FPM Can Consume Lots of RAM

38. Too Many Workers

39. Process CPU

40. CPU Percentage Can Be Misunderstood

41. Load Average

Load Average

42. What Does Load Mean?

43. Example

44. High Load ≠ Automatically Bad

45. CPU Count

46. Process States

47. Zombie Process

48. Why Zombies Exist

Reaping

49. Don’t Panic About One Zombie

50. Killing a Process

51. SIGTERM

52. SIGKILL

53. Why kill -9 Is Not the First Choice

54. Service Restart Is Usually Better

55. Parent Process

Parent Process ID

56. View Parent Process

57. Why Parent/Child Matters

58. Process Lifecycle

59. File Descriptors

File Descriptors

60. Why This Matters

61. File Descriptor Limits

62. Nginx and Many Connections

63. Process Scheduling

64. CPU Time

65. Nice Value

Nice

66. Don’t Tune Nice Randomly

6. `top`

7. `htop`

12. `systemctl`

21. Why `nginx -t`?

53. Why `kill -9` Is Not the First Choice

69. `failed`