Managing Processes and Monitoring System Activity

Every time you run a command, open an application, or start a service on Linux, you create a process. A process is simply an instance of a running program. Think of a program (like Firefox or a web server) as a recipe written on paper—it sits on the disk, doing nothing. A process is a copy of that recipe being actively cooked in the CPU and memory. The Linux kernel (the core of the operating system) is responsible for managing all these processes: giving each one a turn on the CPU, allocating memory, and ensuring they do not interfere with each other.

Each process is identified by a unique numeric ID called the Process ID (PID). The very first process started by the kernel when the system boots is systemd (PID 1). systemd is the mother of all processes—it starts and manages every other process, including services like the SSH server, the web server, and the login manager.

Let us look at how processes are created. A new process is always spawned (created) from an existing parent process through a system call called fork. When you type a command in the terminal, the shell (the command interpreter, like bash) forks itself to create a child process, and that child process then executes the command you typed. This parent-child relationship is hierarchical: every process except systemd has a parent process, identified by the Parent Process ID (PPID).

You can see all running processes using the ps command. Running just ps gives you only the processes in your current terminal. To see every process on the system, use ps aux. Let us break down what these flags mean: a means all processes from all users, u shows the user who owns each process, and x includes processes not attached to a terminal (like daemons). The output shows columns such as USER (who owns the process), PID, %CPU (percentage of CPU usage), %MEM (percentage of RAM usage), VSZ and RSS (virtual and physical memory sizes), STAT (process state—R for running, S for sleeping, D for uninterruptible sleep, Z for zombie), START (when it started), TIME (cumulative CPU time used), and COMMAND (the command that started it).

A more dynamic and continuously updating view is given by the top command. top shows a real-time list of processes sorted by CPU usage by default, updating every few seconds. You can sort by memory using M, kill a process by pressing k and entering its PID, and change the nice value (priority) by pressing r and entering a new value. The header of top displays critical system information:

A zombie process is a process that has finished execution but still has an entry in the process table because its parent has not yet read its exit status. Zombies consume minimal resources but indicate a bug in the parent process. A daemon is a background process that runs continuously, not connected to any terminal—examples include httpd (web server), sshd (SSH server), and crond (scheduler).

Now, how do you send signals to processes? The kill command does exactly what its name suggests—it sends a signal to a process. By default, kill sends SIGTERM (signal 15), which asks the process to terminate gracefully. If a process ignores SIGTERM, you can send SIGKILL (signal 9), which forces immediate termination and cannot be caught or ignored by the process. Other common signals include SIGHUP (signal 1, often used to reload configuration), SIGSTOP (signal 19, pauses execution), and SIGCONT (signal 18, resumes execution). Use kill -l to list all available signals.

To change the priority of a running process, you use the renice command. The priority is called the nice value, which ranges from -20 (highest priority) to +19 (lowest priority). A process with a nice value of -5 gets more CPU time than a process with a nice value of +10. Only the root user can set negative nice values. When starting a new process with a specific nice value, use nice -n [value] command.

Finally, how does the system manage processes when they have finished but their parent has not collected their exit code? They become zombie processes. Regularly check for zombies using ps aux | grep 'Z' to catch those rare situations. If you see a zombie, identify its parent PID and decide whether to restart the parent process to clean it up.

Imagine you work as a junior Linux administrator for a mid-size e-commerce company that runs its website on a Red Hat Enterprise Linux (RHEL) server. It is the day of a big flash sale, and customers are flooding the site. Suddenly, your monitoring system alerts you that the web server is unresponsive.

You SSH into the server (remote access via the command line) and immediately run the top command. The top screen shows that CPU usage is at 95%, and the process at the top of the list is httpd (the Apache web server), chewing up 80% of the CPU. But you also see a second process named perl that is using 15% CPU and 4GB of memory—something unusual, as the site does not run Perl scripts normally. This process is owned by a user apache, which suggests a misconfigured CGI script might have gone haywire.

You decide to investigate the suspicious process. Noting its PID (say 7890), you check its full command line path using ps -fp 7890. It shows /usr/bin/perl /var/www/cgi-bin/broken-script.cgi. You confirm with your lead that this script is not part of the sale, so you decide to stop it. You gently kill it with kill -15 7890 (SIGTERM). After a few seconds, you check top again—the process is still there but now in a zombie state. This means the parent process (Apache, PID 1234) has not cleaned it up. You send SIGHUP to Apache: kill -1 1234, which reloads Apache and clears the zombie. The CPU drops back to 20%.

But the sale continues, and load increases. You now want to ensure the web server gets more CPU priority than other services like the backup script that runs on the same server. You use renice -n -5 -p 1234 to give the web server a higher priority. You also check memory usage using free -h (human-readable). You see only 500MB free—close to swap usage. You identify another process consuming too much RAM and decide to delay a non-critical service using systemctl stop some-daemon.service.

Later, you need to analyse historical performance. You check the system log /var/log/messages and use journalctl -xe to see recent boot messages and errors. You also set up a cron job to collect top output every hour into a log file for future analysis.

Finally, you want to see the entire process tree. You run pstree, which shows systemd at the root, then branches like sshd, httpd, crond, and bash. This visualises which parent processes own which children and helps you understand the relationship between services.

Key tools you used: - top: real-time monitoring - ps aux: listing all processes - kill: sending signals - renice: adjusting priority - free: checking memory - systemctl: controlling systemd services - journalctl: viewing logs - pstree: visualising the process hierarchy