Processes

Processes in Linux

A process is a running instance of a program. Whenever Linux
starts an application, command or system service, the operating system
creates and manages a process for it.

Understanding processes is important for Linux administration and
cybersecurity because analysts often need to determine which programs are
running, which users started them, how much system resources they consume and
whether their behavior is expected.

1. Program vs Process

A program is a set of instructions stored on a system. A process is an
active execution of that program.

For example, a web-server program may be installed on a Linux system without
actively processing requests. When the web server starts, Linux creates one
or more processes associated with that service.

The distinction is useful:

• Program: Stored instructions.
• Process: A running instance of those instructions.

2. Process IDs — PID

Linux normally assigns each process a numeric identifier called a
PID, or Process ID.

The PID allows administrators and operating-system tools to identify a
specific running process.

For example:

PID
2450

The actual PID values on your machine will be different.

3. Parent Process IDs — PPID

Processes can have parent-child relationships.

A process may have a PPID, meaning Parent Process ID. This
identifies the process that created or launched it in the relevant process
relationship.

Process trees can therefore help analysts understand how a program was
started.

4. Process Trees

A process tree represents relationships between processes.

Conceptually:

Parent Process
      |
      +---- Child Process
               |
               +---- Another Child Process

This can be useful during security investigations because unexpected child
processes may require additional investigation.

However, the presence of an unusual process relationship alone does not prove
malicious activity. Analysts should examine additional evidence.

5. Inspecting Processes with ps

The ps command provides information about running processes.

For example:

ps

A commonly used view is:

ps aux

Depending on the Linux distribution, command options can vary. Students
should use the documentation available on their specific system.

The output can contain information such as:

• User.
• PID.
• CPU usage.
• Memory usage.
• Start time.
• Command.

6. Real-Time Monitoring with top

The top command provides a continuously updated view of system
processes.

top

It can help administrators observe CPU and memory consumption.

For example, if a system suddenly becomes slow, an administrator may use
top to determine whether a process is consuming an unusual
amount of CPU or memory.

7. htop

Some Linux systems provide htop, an interactive process-monitoring
utility.

htop

It is often easier to navigate than traditional top, although
it may not be installed by default.

8. Finding Processes

Utilities such as pgrep can help identify processes associated
with a particular name or pattern.

pgrep ssh

Another utility, pidof, may return process IDs associated with a
specified program.

pidof ssh

Always verify the output before taking administrative action.

9. Foreground Processes

A foreground process normally occupies the current terminal session.

For example:

ping 127.0.0.1

The command can continue producing output while the terminal waits for the
process to finish or for the user to interrupt it.

10. Background Processes

Linux shells can also run processes in the background.

A command can commonly be placed in the background using the shell’s
background operator:

command &

The exact behavior depends on the shell and terminal session.

Background execution is useful when an administrator wants to continue using
the terminal while another task continues running.

11. Jobs

Shell jobs are related to processes controlled by the current shell.

Useful commands include:

jobs
bg
fg

These commands help users manage processes that were started from the current
interactive shell.

12. Process States

Linux processes can exist in different states depending on what they are
doing.

Common process-state concepts include:

• Running: The process is executing or ready to execute.
• Sleeping: The process is waiting for an event or resource.
• Stopped: Execution has been temporarily suspended.
• Zombie: The process has finished but its parent has not yet collected its termination status.

The exact state codes displayed by tools such as ps should be
interpreted using the documentation for the specific command.

13. Signals

Linux uses signals as a mechanism for communicating with processes.

For example, a termination request can be sent using:

kill -TERM <PID>

The TERM signal asks the process to terminate and gives it an
opportunity to perform normal cleanup.

A stronger signal exists that can immediately stop a process, but it should
not be treated as the first choice because the process may not have an
opportunity to clean up resources.

14. Why Process Termination Requires Care

Stopping the wrong process can interrupt an application, disconnect users,
damage an ongoing operation or make a service unavailable.

Before terminating a process, administrators should verify:

• The PID.
• The process name.
• The process owner.
• The command that started it.
• Whether it belongs to a critical service.
• Whether the action is authorized.

15. Daemons

A daemon is a background process that commonly provides a
system or application service.

Examples may include:

• Web servers.
• SSH services.
• Database services.
• Logging services.
• Scheduled-task services.

Different Linux systems use different service-management technologies, with
systemd being common on many modern distributions.

16. systemctl

On systemd-based systems, systemctl is commonly used to inspect
and manage services.

For example:

systemctl status ssh

The exact service name can vary between distributions. Some systems may use
names such as sshd instead.

Students should first identify the correct service name rather than assuming
that every Linux system uses the same naming convention.

17. Process Ownership

Processes are associated with user identities.

This relationship is important for security because a process normally has
access according to the privileges of the identity under which it runs.

A process running with excessive privileges can therefore have a greater
potential impact if compromised.

18. Process Resource Usage

Administrators commonly monitor:

• CPU usage.
• Memory usage.
• Process count.
• Disk activity.
• Network activity.
• Process start time.

Unexpected resource consumption can indicate a legitimate performance
problem, a misconfigured application or a possible security event.

19. Processes and Cybersecurity

Security analysts may inspect processes when investigating:

• Unexpected applications.
• Unusual resource consumption.
• Unauthorized services.
• Unexpected administrative activity.
• Suspicious parent-child relationships.
• Programs running under unexpected accounts.
• Persistence mechanisms.

Process information should be combined with logs, file information, network
connections and other evidence.

20. An Important Investigation Principle

A process name that looks unfamiliar is not automatically malicious.
Legitimate software can have unfamiliar names, and malware can sometimes use
names that appear legitimate.

A responsible investigation should therefore consider:

1. Process name.
2. Full command line where available.
3. Process owner.
4. Parent process.
5. Executable location.
6. File metadata or hash.
7. Network activity.
8. System logs.
9. Expected system configuration.

21. Process Investigation Scenario

Imagine a Linux server suddenly experiences high CPU usage.

A structured investigation might begin by checking:

top

The analyst may then identify the process consuming the most CPU and inspect
its PID, owner and command.

The analyst can then correlate the process with:

• Recent software changes.
• System logs.
• Application logs.
• Network connections.
• File modifications.
• Scheduled tasks.

This approach is more reliable than immediately terminating an unfamiliar
process without investigation.

22. Process Trees During Investigation

A process tree can help answer questions such as:

• Which process started this process?
• Which user owns it?
• Was it started by a service?
• Was it launched from an interactive shell?
• Are there unexpected child processes?

This information can provide useful context during incident response.

23. Safe Process Laboratory

Use only your own Linux virtual machine or another explicitly authorized
training environment.

Exercise:

1. Run ps and observe the output.
2. Run ps aux.
3. Identify your current shell process.
4. Run top and observe CPU and memory usage.
5. If available, inspect the process tree using an appropriate tool.
6. Start a harmless foreground command.
7. Experiment with shell job control.
8. Inspect the process ID of the laboratory command.
9. Stop the laboratory process normally.
10. Document what you observed.

24. Useful Commands

ps
ps aux
top
htop
pgrep
pidof
jobs
bg
fg
systemctl status <service>
kill -TERM <PID>

These commands should be used responsibly. Do not terminate processes on
systems that you do not own or administer.

25. PHP Example — Synthetic Process Monitoring

The following PHP example demonstrates process-risk logic using synthetic
data. It does not inspect, terminate or manipulate real operating-system
processes.

<?php

$process = array(
    'name'        => 'training-service',
    'pid'         => 2450,
    'cpu_percent' => 12.5,
    'memory_mb'   => 180,
    'owner'       => 'student001',
    'unknown'     => false,
);

$risk_flags = array();

if ( $process['unknown'] ) {
    $risk_flags[] = 'Unknown process requires investigation.';
}

if ( $process['cpu_percent'] > 90 ) {
    $risk_flags[] = 'Very high CPU usage detected.';
}

if ( $process['memory_mb'] > 2048 ) {
    $risk_flags[] = 'High memory usage detected.';
}

if ( empty( $risk_flags ) ) {

    echo 'No synthetic process-risk indicators detected.';

} else {

    echo implode(
        '<br>',
        array_map( 'esc_html', $risk_flags )
    );
}

26. Practical Assignment

In your authorized Linux laboratory, prepare a short process-monitoring
report containing:

1. What a process is.
2. The difference between a program and a process.
3. The meaning of PID and PPID.
4. Three commands used to inspect processes.
5. The purpose of top.
6. The meaning of a daemon.
7. The purpose of process signals.
8. Why administrators should verify a PID before terminating a process.
9. Three pieces of evidence that can help investigate a suspicious process.

27. Review Questions

1. What is a process?
2. What is a PID?
3. What is a PPID?
4. What is the difference between a foreground and background process?
5. What is the purpose of ps?
6. What does top help an administrator observe?
7. What is a daemon?
8. What is a signal?
9. Why should process termination be performed carefully?
10. Why can process monitoring be useful during cybersecurity investigations?

28. Key Takeaways

• A process is a running instance of a program.
• Linux identifies processes using PIDs.
• PPIDs help describe parent-child process relationships.
• Commands such as ps and top are fundamental monitoring tools.
• Signals provide mechanisms for communicating with processes.
• Daemons provide many background system and application services.
• Process ownership and privileges are important cybersecurity considerations.
• Unexpected CPU or memory consumption can justify further investigation.
• Security analysts should correlate process information with other evidence.
• Process administration should always be performed within an authorized environment.

Conclusion

Processes are at the center of Linux system activity. By learning how to
identify, monitor and understand processes, cybersecurity students gain an
important foundation for system administration, performance troubleshooting
and incident investigation.

The next lesson will examine Basic Networking Commands and
show how Linux administrators inspect interfaces, addresses, routes, DNS and
network connections.