{"id":161439,"date":"2026-03-19T02:14:50","date_gmt":"2026-03-18T23:14:50","guid":{"rendered":"https:\/\/cloudspinx.com\/?p=81951"},"modified":"2026-03-19T02:14:55","modified_gmt":"2026-03-18T23:14:55","slug":"managing-linux-processes-commands","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/managing-linux-processes-commands\/","title":{"rendered":"Managing Linux Processes with ps, top, kill, bg and fg"},"content":{"rendered":"\n<p>Every running program on a Linux system is a process. Whether it is the shell you are typing commands into, a web server handling thousands of requests, or a database crunching queries, it is all processes under the hood. Understanding how to inspect, control, prioritize, and terminate processes is a core sysadmin skill and a major topic on the LPIC-1 certification exams.<\/p>\n\n\n\n<p>This guide covers everything you need to know about Linux process management, from the fundamentals through advanced techniques. Every command shown here was tested on systems running recent kernels (6.x series) with systemd, but the concepts apply across all major distributions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. What Is a Process?<\/h2>\n\n\n\n<p>A process is an instance of a running program. When you launch <code>\/usr\/bin\/vim<\/code>, the kernel allocates memory, assigns a unique identifier, and begins executing the binary. That running instance is a process. The binary sitting on disk is just a file; the process is the living, breathing execution of that file.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key Process Attributes<\/h3>\n\n\n\n<p><strong>PID (Process ID)<\/strong> is the unique integer the kernel assigns to every process. PIDs start at 1 (which belongs to the init system, typically systemd on modern distributions) and increment from there. The kernel recycles PIDs after a process exits, but the maximum PID value is configurable via <code>\/proc\/sys\/kernel\/pid_max<\/code>.<\/p>\n\n\n\n<p><strong>PPID (Parent Process ID)<\/strong> tracks which process spawned the current one. Every process (except PID 1) has a parent. When you run <code>ls<\/code> from your bash shell, the bash process forks a child, and that child&#8217;s PPID is your shell&#8217;s PID. This parent\/child relationship forms a tree structure you can visualize with <code>pstree<\/code>.<\/p>\n\n\n\n<p><strong>UID\/GID<\/strong> determine what the process is allowed to do. Processes inherit the user and group identity of the account that started them, unless special mechanisms like setuid bits or capabilities alter that.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Process States<\/h3>\n\n\n\n<p>At any given moment, a process is in one of several states. You will see these as single-letter codes in tools like <code>ps<\/code> and <code>top<\/code>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>R (Running)<\/strong> : The process is either executing on a CPU core right now or sitting in the run queue ready to execute.<\/li>\n<li><strong>S (Sleeping)<\/strong> : The process is waiting for an event, such as I\/O completion or a timer. This is the most common state for idle services.<\/li>\n<li><strong>D (Uninterruptible Sleep)<\/strong> : The process is waiting for I\/O (usually disk) and cannot be interrupted. Processes stuck in D state often indicate storage or NFS problems.<\/li>\n<li><strong>T (Stopped)<\/strong> : The process has been paused, typically by a SIGSTOP or SIGTSTP signal (Ctrl+Z from the terminal).<\/li>\n<li><strong>Z (Zombie)<\/strong> : The process has finished execution but its parent has not yet read its exit status. More on this later.<\/li>\n<li><strong>I (Idle)<\/strong> : A kernel thread state introduced in Linux 4.14, representing kernel threads that are idle.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Foreground vs Background Processes<\/h3>\n\n\n\n<p>A <strong>foreground process<\/strong> holds the terminal. You cannot type another command until it finishes or you suspend it. A <strong>background process<\/strong> runs without holding the terminal, letting you keep working. Every sysadmin needs to move processes between foreground and background routinely. We cover the mechanics in Section 5.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. The ps Command: Deep Dive<\/h2>\n\n\n\n<p>The <code>ps<\/code> command produces a snapshot of current processes. It does not update in real time (unlike <code>top<\/code>). There are two major syntax styles: BSD style (no leading dash) and UNIX\/POSIX style (with dashes). Both are valid and you will see both in the wild.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">ps aux: The Classic BSD-Style Listing<\/h3>\n\n\n\n<p>This is the single most commonly used <code>ps<\/code> invocation. It shows all processes from all users with a human-readable format.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps aux<\/code><\/pre>\n\n\n\n<p>Sample output (truncated):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nroot         1  0.0  0.1 171636 13292 ?        Ss   Mar15   0:05 \/usr\/lib\/systemd\/systemd\nroot         2  0.0  0.0      0     0 ?        S    Mar15   0:00 [kthreadd]\nwww-data  4521  2.3  1.4 524288 58432 ?        Sl   09:12   1:42 \/usr\/sbin\/apache2 -k start\njdoe      7891  0.0  0.2  22456  8320 pts\/0    Ss   10:30   0:00 -bash\njdoe      8024  0.0  0.0  10080  3200 pts\/0    R+   11:05   0:00 ps aux<\/code><\/pre>\n\n\n\n<p>The columns break down as follows. <strong>USER<\/strong> is the process owner. <strong>PID<\/strong> is the process ID. <strong>%CPU<\/strong> and <strong>%MEM<\/strong> show resource usage. <strong>VSZ<\/strong> is virtual memory size in KB. <strong>RSS<\/strong> is resident set size (actual physical memory used) in KB. <strong>TTY<\/strong> is the controlling terminal (? means no terminal, common for daemons). <strong>STAT<\/strong> is the process state plus modifiers (s = session leader, + = foreground process group, l = multi-threaded). <strong>START<\/strong> is when the process launched. <strong>TIME<\/strong> is cumulative CPU time. <strong>COMMAND<\/strong> is the full command line.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">ps -ef: The POSIX-Style Listing<\/h3>\n\n\n\n<p>This is the POSIX equivalent and is equally common.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -ef<\/code><\/pre>\n\n\n\n<p>Sample output:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>UID        PID  PPID  C STIME TTY          TIME CMD\nroot         1     0  0 Mar15 ?        00:00:05 \/usr\/lib\/systemd\/systemd\nroot         2     0  0 Mar15 ?        00:00:00 [kthreadd]\nwww-data  4521  4500  2 09:12 ?        00:01:42 \/usr\/sbin\/apache2 -k start<\/code><\/pre>\n\n\n\n<p>The key difference is that <code>ps -ef<\/code> includes the PPID column, which is useful when you need to trace parent\/child relationships.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Custom Output with ps -eo<\/h3>\n\n\n\n<p>The <code>-o<\/code> flag lets you select exactly which columns you want. This is powerful for scripting and targeted troubleshooting.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -eo pid,ppid,user,nice,stat,%cpu,%mem,comm --sort=-%cpu | head -15<\/code><\/pre>\n\n\n\n<p>That command lists processes sorted by CPU usage (descending), showing only the fields you care about. The <code>--sort<\/code> flag accepts any column name; prefix with <code>-<\/code> for descending order.<\/p>\n\n\n\n<p>Another practical example shows process start time and elapsed time:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -eo pid,user,lstart,etime,comm --sort=-etime | head -20<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Filtering Processes<\/h3>\n\n\n\n<p>Filter by username with <code>-u<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -u www-data -o pid,%cpu,%mem,comm<\/code><\/pre>\n\n\n\n<p>Filter by process name with <code>-C<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -C nginx -o pid,ppid,%cpu,%mem,stat<\/code><\/pre>\n\n\n\n<p>Filter by PID with <code>-p<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -p 1,4521,7891 -o pid,user,comm,stat<\/code><\/pre>\n\n\n\n<p>Piping through <code>grep<\/code> is another common approach. Use brackets around the first character to avoid matching the grep process itself:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps aux | grep '[n]ginx'<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Process Trees with ps<\/h3>\n\n\n\n<p>Visualize the parent\/child hierarchy:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps auxf<\/code><\/pre>\n\n\n\n<p>Or use the dedicated tree command for a cleaner view:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>pstree -p<\/code><\/pre>\n\n\n\n<p>The <code>-p<\/code> flag shows PIDs alongside the tree structure. Add <code>-u<\/code> to see UID transitions (useful for spotting privilege changes).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Real-Time Monitoring: top and htop<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">top: The Built-In Monitor<\/h3>\n\n\n\n<p>While <code>ps<\/code> gives you a snapshot, <code>top<\/code> gives you a live, updating view. Launch it with:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>top<\/code><\/pre>\n\n\n\n<p>The header area shows system-wide stats: uptime, load averages, total tasks broken down by state, CPU usage split into user\/system\/nice\/idle\/iowait\/irq\/softirq\/steal, and memory\/swap usage.<\/p>\n\n\n\n<p>Key interactive commands while <code>top<\/code> is running:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>P<\/strong> : Sort by CPU usage (default).<\/li>\n<li><strong>M<\/strong> : Sort by memory usage.<\/li>\n<li><strong>T<\/strong> : Sort by cumulative time.<\/li>\n<li><strong>k<\/strong> : Kill a process. It prompts for the PID and the signal to send.<\/li>\n<li><strong>r<\/strong> : Renice a process. Prompts for PID and new nice value.<\/li>\n<li><strong>u<\/strong> : Filter to show only one user&#8217;s processes.<\/li>\n<li><strong>c<\/strong> : Toggle between showing the command name and the full command line.<\/li>\n<li><strong>1<\/strong> : Toggle per-CPU core breakdown (extremely useful on multi-core systems).<\/li>\n<li><strong>H<\/strong> : Toggle thread display.<\/li>\n<li><strong>f<\/strong> : Open the field management screen to add, remove, or reorder columns.<\/li>\n<li><strong>W<\/strong> : Write your current settings to <code>~\/.toprc<\/code> so they persist.<\/li>\n<li><strong>q<\/strong> : Quit.<\/li>\n<\/ul>\n\n\n\n<p>You can also launch <code>top<\/code> in batch mode for scripting. This runs it once and exits:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>top -bn1 | head -20<\/code><\/pre>\n\n\n\n<p>Filter by a specific user from the command line:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>top -u postgres<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">htop: The Better Interactive Monitor<\/h3>\n\n\n\n<p>The <code>htop<\/code> utility is a more user-friendly alternative. Install it if it is not already present:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>## Debian\/Ubuntu\nsudo apt install htop\n\n## RHEL\/Fedora\/Rocky\nsudo dnf install htop<\/code><\/pre>\n\n\n\n<p>Launch it with:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>htop<\/code><\/pre>\n\n\n\n<p>What makes <code>htop<\/code> better for day-to-day work:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Color-coded CPU and memory bars at the top give you an instant visual read on system load.<\/li>\n<li>Mouse support. You can click column headers to sort, click processes to select them, and use the function key bar at the bottom.<\/li>\n<li>Built-in tree view. Press <strong>F5<\/strong> to toggle the process tree.<\/li>\n<li>Incremental search. Press <strong>F3<\/strong> (or <strong>\/<\/strong>) and start typing to find a process by name.<\/li>\n<li>Filter. Press <strong>F4<\/strong> to filter the process list to show only matching entries.<\/li>\n<li>Multiple sort options. Press <strong>F6<\/strong> to choose the sort column from a sidebar.<\/li>\n<li>You can send signals without memorizing numbers. Press <strong>F9<\/strong> to bring up a signal selection menu.<\/li>\n<li>Press <strong>F2<\/strong> to open the setup screen where you can customize meters, colors, and layout. Changes save to <code>~\/.config\/htop\/htoprc<\/code>.<\/li>\n<\/ul>\n\n\n\n<p>For servers where you prefer a terminal-based dashboard, <code>htop<\/code> is the go-to tool. On headless systems, it is usually one of the first packages I install.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Process Priority: nice and renice<\/h2>\n\n\n\n<p>The Linux scheduler decides which processes get CPU time. You can influence this decision using <strong>nice values<\/strong>. Nice values range from <strong>-20<\/strong> (highest priority, least &#8220;nice&#8221; to other processes) to <strong>19<\/strong> (lowest priority, most &#8220;nice&#8221;). The default nice value for a new process is 0.<\/p>\n\n\n\n<p>Only root can set negative nice values (raise priority). Regular users can only make their processes nicer (lower priority), not less nice.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Starting a Process with a Custom Nice Value<\/h3>\n\n\n\n<p>Use the <code>nice<\/code> command to launch a process at a specific priority:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>nice -n 10 tar czf \/backup\/archive.tar.gz \/home<\/code><\/pre>\n\n\n\n<p>That runs the backup at a lower priority so it does not starve interactive users of CPU. This is a classic use case: long-running batch work that should yield to interactive workloads.<\/p>\n\n\n\n<p>To start something at maximum priority (as root):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo nice -n -20 \/opt\/critical-app\/run.sh<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Changing Priority of a Running Process<\/h3>\n\n\n\n<p>Use <code>renice<\/code> to adjust the priority of an already-running process:<\/p>\n\n<!-- \/wp:post-content -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>renice -n 15 -p 4521<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>You can also renice all processes belonging to a user:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sudo renice -n 5 -u www-data<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Check a process&#8217;s current nice value:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -o pid,ni,comm -p 4521<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The NI column in <code>top<\/code> and <code>htop<\/code> also shows the nice value. Remember that nice values affect CPU scheduling only. They have no effect on I\/O priority. For I\/O scheduling priority, look into <code>ionice<\/code>.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>5. Background and Foreground Process Control<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Managing foreground and background processes is something you will do dozens of times a day in a terminal. Here is the full workflow.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Running a Process in the Background<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Append <code>&<\/code> to any command to run it in the background immediately:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>rsync -av \/data\/ \/backup\/data\/ &<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The shell prints the job number and PID:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>[1] 12345<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Suspending a Foreground Process<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Press <strong>Ctrl+Z<\/strong> to suspend (stop) the current foreground process. It does not terminate; it pauses. You will see output like:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>[1]+  Stopped                 rsync -av \/data\/ \/backup\/data\/<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>jobs, bg, and fg<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>List all jobs in the current shell session:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>jobs -l<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>-l<\/code> flag includes PIDs in the listing. Sample output:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>[1]+ 12345 Stopped                 rsync -av \/data\/ \/backup\/data\/\n[2]- 12400 Running                 find \/ -name \"*.log\" > \/tmp\/logs.txt &<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Resume a stopped job in the background:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>bg %1<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Bring a background job to the foreground:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>fg %1<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>%1<\/code> refers to job number 1. You can also use <code>%<\/code> followed by a string that matches the command name, like <code>fg %rsync<\/code>.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Surviving Logout: nohup and disown<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Background processes normally receive a SIGHUP signal when you close the terminal, which terminates them. Two tools prevent this.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>The <code>nohup<\/code> command makes a process immune to SIGHUP from the start:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>nohup .\/long-running-script.sh &<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Output that would normally go to the terminal is redirected to <code>nohup.out<\/code> (or you can redirect it explicitly):<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>nohup .\/long-running-script.sh > \/var\/log\/myscript.log 2>&1 &<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>If you forgot to use <code>nohup<\/code> and the process is already running, use <code>disown<\/code>:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>disown %1<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>After <code>disown<\/code>, the job is removed from the shell&#8217;s job table and will not receive SIGHUP when the shell exits. This is a lifesaver when you realize mid-task that you should have used <code>nohup<\/code> or a terminal multiplexer.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>For anything long-running on a production server, consider <code>tmux<\/code> or <code>screen<\/code> instead. They give you a persistent session you can detach from and reattach to later.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>6. Sending Signals: kill, killall, and pkill<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Signals are the kernel&#8217;s mechanism for communicating with processes. You send signals to tell a process to terminate, reload its configuration, dump a core, or take other actions.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Common Signals<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The most important signals every admin should know:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list -->\n<ul>\n<li><strong>SIGTERM (15)<\/strong> : Graceful termination. The process receives the signal and has the opportunity to clean up (close files, remove temp files, finish transactions) before exiting. This is the default signal sent by <code>kill<\/code>.<\/li>\n<li><strong>SIGKILL (9)<\/strong> : Forceful termination. The kernel immediately removes the process. The process gets no chance to clean up. Use this only when SIGTERM does not work. It cannot be caught, blocked, or ignored by the process.<\/li>\n<li><strong>SIGHUP (1)<\/strong> : Historically meant &#8220;hangup&#8221; (as in a modem disconnection). Many daemons interpret SIGHUP as an instruction to reload their configuration files without restarting. For example, sending SIGHUP to Nginx causes it to re-read nginx.conf.<\/li>\n<li><strong>SIGINT (2)<\/strong> : This is what Ctrl+C sends. It is an interrupt signal requesting the process to terminate.<\/li>\n<li><strong>SIGSTOP (19)<\/strong> : Pauses the process. Like SIGKILL, it cannot be caught or ignored. The process freezes until it receives SIGCONT.<\/li>\n<li><strong>SIGCONT (18)<\/strong> : Resumes a stopped process.<\/li>\n<li><strong>SIGUSR1 (10) and SIGUSR2 (12)<\/strong> : User-defined signals. Applications use these for custom behavior. For instance, sending SIGUSR1 to some applications triggers a log rotation or status dump.<\/li>\n<\/ul>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>List all available signals on your system:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>kill -l<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>kill: Send a Signal by PID<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The <code>kill<\/code> command sends a signal to a specific PID. Despite the name, it does not always kill processes; it sends whatever signal you specify.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>## Send SIGTERM (default, graceful)\nkill 4521\n\n## Send SIGKILL (forceful)\nkill -9 4521\n\n## Send SIGHUP (reload config)\nkill -HUP 4521\n\n## Send using signal name\nkill -SIGTERM 4521<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The recommended approach is to always try SIGTERM first. Give the process a few seconds, then check if it is still running. Only escalate to SIGKILL if necessary.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>killall: Send a Signal by Process Name<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The <code>killall<\/code> command targets all processes matching a given name:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>killall nginx<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Be careful with <code>killall<\/code>. It matches by the process name exactly. If you have multiple services with workers sharing a name, you might terminate more than intended. You can add <code>-i<\/code> for interactive mode, which prompts for confirmation on each match:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>killall -i python3<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Send SIGHUP to reload all instances:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>killall -HUP nginx<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>pkill: Send a Signal with Pattern Matching<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The <code>pkill<\/code> command is more flexible than <code>killall<\/code> because it uses pattern matching (regex):<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>## Kill processes matching a pattern\npkill -f \"python3 \/opt\/myapp\/server.py\"\n\n## Kill by user\npkill -u jdoe\n\n## Kill by user AND pattern\npkill -u jdoe python3<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>-f<\/code> flag matches against the full command line rather than just the process name. This is extremely useful when you have multiple Python scripts running and need to target a specific one.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>7. Process Monitoring Tools<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>watch: Repeat a Command at Intervals<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>The <code>watch<\/code> command runs any command repeatedly and displays the output in a full-screen view. It is perfect for monitoring processes over time.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>watch -n 2 'ps -eo pid,%cpu,%mem,comm --sort=-%cpu | head -15'<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>That refreshes every 2 seconds, showing the top 15 CPU consumers. Add <code>-d<\/code> to highlight differences between updates:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>watch -d -n 5 'ps aux | wc -l'<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>The \/proc Filesystem<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Every running process has a directory under <code>\/proc<\/code> named after its PID. This virtual filesystem is the kernel&#8217;s window into process internals.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ls \/proc\/1\/<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Useful files inside <code>\/proc\/[PID]\/<\/code>:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list -->\n<ul>\n<li><strong>cmdline<\/strong> : The full command line used to start the process.<\/li>\n<li><strong>status<\/strong> : Human-readable status including name, state, PID, PPID, UID, memory usage, and more.<\/li>\n<li><strong>fd\/<\/strong> : Directory of symbolic links to all open file descriptors.<\/li>\n<li><strong>environ<\/strong> : The environment variables the process was started with.<\/li>\n<li><strong>maps<\/strong> : Memory mappings.<\/li>\n<li><strong>limits<\/strong> : Current resource limits (soft and hard) for the process.<\/li>\n<li><strong>io<\/strong> : I\/O statistics (bytes read\/written).<\/li>\n<\/ul>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>Check what a process&#8217;s current resource limits are:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>cat \/proc\/4521\/limits<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Count how many file descriptors a process has open:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ls \/proc\/4521\/fd | wc -l<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Read a process&#8217;s current status:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>cat \/proc\/4521\/status<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>pidof and pgrep<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Find the PID of a running program by its name:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>pidof sshd<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Sample output:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>985 22410 22450<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>pgrep<\/code> command is more flexible and supports pattern matching and various filters:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>## Find PIDs by name pattern\npgrep -a nginx\n\n## Find PIDs owned by a user\npgrep -u postgres\n\n## Count matching processes\npgrep -c apache2\n\n## Show only the newest match\npgrep --newest sshd<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>-a<\/code> flag shows the full command line alongside the PID, which is helpful when you need to distinguish between multiple instances of the same binary.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>8. Managing Service Processes with systemctl<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>On any modern Linux system running systemd, services (long-running daemons) are managed through <code>systemctl<\/code>. This is the standard interface for starting, stopping, and inspecting service processes.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>## Check if a service is running\nsystemctl status nginx\n\n## Start a service\nsudo systemctl start nginx\n\n## Stop a service\nsudo systemctl stop nginx\n\n## Restart (stop then start)\nsudo systemctl restart nginx\n\n## Reload configuration without full restart\nsudo systemctl reload nginx\n\n## Enable a service to start at boot\nsudo systemctl enable nginx\n\n## Disable a service from starting at boot\nsudo systemctl disable nginx<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>systemctl status<\/code> output is rich. It shows the service&#8217;s active state, the main PID, memory usage, recent log lines, and the cgroup the service belongs to.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>List all running services:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>systemctl list-units --type=service --state=running<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>List all failed services (useful when troubleshooting after a reboot):<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>systemctl list-units --type=service --state=failed<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>See the full logs for a service:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>journalctl -u nginx -f<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>-f<\/code> flag follows the log in real time, similar to <code>tail -f<\/code>.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>9. cgroups and Resource Limits<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Control groups (cgroups) are a kernel feature that lets you allocate, limit, and monitor system resources (CPU, memory, I\/O, network) for groups of processes. Every systemd service automatically runs inside its own cgroup, which is why <code>systemctl status<\/code> can show per-service memory usage.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Viewing cgroup Information<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>See which cgroup a process belongs to:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>cat \/proc\/4521\/cgroup<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>View resource usage for a systemd service slice:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>systemd-cgtop<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The <code>systemd-cgtop<\/code> command works like <code>top<\/code> but shows resource usage organized by cgroup (which maps to services, slices, and scopes in systemd).<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Setting Resource Limits on Services<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>You can cap the resources a service is allowed to consume by editing its systemd unit file or using an override:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sudo systemctl edit nginx<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>In the editor, add resource limits under the <code>[Service]<\/code> section:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>[Service]\nMemoryMax=512M\nCPUQuota=50%\nTasksMax=200<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p><strong>MemoryMax<\/strong> caps the total memory the service and all its children can use. If the limit is hit, the kernel&#8217;s OOM killer terminates processes in that cgroup. <strong>CPUQuota<\/strong> limits CPU time as a percentage (100% equals one full core). <strong>TasksMax<\/strong> limits the number of tasks (processes and threads) the service can spawn, which is a good defense against fork bombs.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>After saving, reload and restart:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sudo systemctl daemon-reload\nsudo systemctl restart nginx<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Per-User and Per-Session Limits with ulimit<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Traditional resource limits set via <code>ulimit<\/code> still apply and are still relevant. View current limits:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ulimit -a<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Common limits you might adjust:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>## Max open files for current session\nulimit -n 65535\n\n## Max user processes\nulimit -u 4096<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>For persistent limits, edit <code>\/etc\/security\/limits.conf<\/code> or drop a file in <code>\/etc\/security\/limits.d\/<\/code>.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>10. Zombie and Orphan Processes<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>These are two special cases in process lifecycle management that come up in exams and in real-world troubleshooting.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Zombie Processes<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>A zombie (or defunct) process is one that has finished executing but still has an entry in the process table. This happens because the parent process has not yet called <code>wait()<\/code> to read the child&#8217;s exit status. The zombie consumes no CPU or memory beyond its entry in the process table, but each one takes up a PID slot.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Find zombie processes:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps aux | awk '$8 ~ \/^Z\/ {print}'<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Or more simply:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo pid,ppid,stat,comm | grep -w Z<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>You cannot kill a zombie directly. It is already dead. The proper fix is to make the parent process call <code>wait()<\/code>. You can nudge the parent by sending it SIGCHLD:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>kill -SIGCHLD &lt;parent_pid&gt;<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>If the parent ignores SIGCHLD or is buggy, your options are:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list {\"ordered\":true} -->\n<ol>\n<li>Kill the parent process. When the parent dies, the zombies become orphans and are adopted by PID 1 (systemd), which will reap them.<\/li>\n<li>Fix the parent application&#8217;s code so it properly handles child process exit.<\/li>\n<\/ol>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>A few zombies are not a problem. Thousands of them indicate a broken application that is not cleaning up its children.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Orphan Processes<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>An orphan process is one whose parent has exited while the child is still running. The kernel automatically re-parents orphans to PID 1 (the init system). On systemd-based systems, systemd takes over as the parent and will properly reap these processes when they exit.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>Orphan processes are generally not a problem in normal operation. They become noteworthy when a service&#8217;s main process crashes and leaves worker children running without supervision. Find processes whose parent is PID 1 but probably should not be:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo pid,ppid,user,comm | awk '$2 == 1 && $3 != \"root\"'<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>That shows non-root processes parented to PID 1, which might be orphaned workers worth investigating.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>11. Useful One-Liners for Daily Work<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>These are commands I keep in my back pocket for quick troubleshooting. Each one solves a common question you will face as a sysadmin.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Top 10 Memory Consumers<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo pid,user,%mem,rss,comm --sort=-%mem | head -11<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Top 10 CPU Consumers<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo pid,user,%cpu,comm --sort=-%cpu | head -11<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Full Process Tree<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>pstree -pua<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>The flags: <code>-p<\/code> shows PIDs, <code>-u<\/code> shows UID transitions, <code>-a<\/code> shows command line arguments.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Count Processes Per User<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo user= | sort | uniq -c | sort -rn | head -10<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Find All Processes Using a Specific Port<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ss -tlnp | grep ':80 '<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Find Processes with High Open File Descriptor Count<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>for pid in \/proc\/[0-9]*\/fd; do\n  count=$(ls \"$pid\" 2>\/dev\/null | wc -l)\n  if [ \"$count\" -gt 100 ]; then\n    p=$(echo \"$pid\" | cut -d\/ -f3)\n    echo \"$count $p $(cat \/proc\/$p\/comm 2>\/dev\/null)\"\n  fi\ndone | sort -rn | head -10<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Watch for Zombie Processes in Real Time<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>watch -n 5 'ps -eo stat | grep -c Z'<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Show Processes That Have Been Running the Longest<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>ps -eo pid,etime,user,comm --sort=-etime | head -15<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading {\"level\":3} -->\n<h3>Kill All Processes Belonging to a User<\/h3>\n<!-- \/wp:heading -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sudo pkill -u jdoe<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:paragraph -->\n<p>Or the nuclear option that also forces logout:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:code -->\n<pre class=\"wp-block-code\"><code>sudo loginctl terminate-user jdoe<\/code><\/pre>\n<!-- \/wp:code -->\n\n<!-- wp:heading -->\n<h2>12. LPIC Exam Relevance<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Process management is heavily tested on the LPIC-1 certification (exams 101 and 102). Specifically, these topics map to the following exam objectives:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list -->\n<ul>\n<li><strong>Topic 103.5: Create, monitor and kill processes<\/strong> (Exam 101, weight 4). This covers <code>ps<\/code>, <code>top<\/code>, <code>kill<\/code>, <code>killall<\/code>, <code>bg<\/code>, <code>fg<\/code>, <code>jobs<\/code>, <code>nohup<\/code>, <code>watch<\/code>, <code>free<\/code>, <code>uptime<\/code>, and <code>screen<\/code>\/<code>tmux<\/code>.<\/li>\n<li><strong>Topic 103.6: Modify process execution priorities<\/strong> (Exam 101, weight 2). This covers <code>nice<\/code>, <code>renice<\/code>, and understanding the nice value range.<\/li>\n<\/ul>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>For the LPIC-1, focus especially on these areas:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list {\"ordered\":true} -->\n<ol>\n<li><strong>Know the signal numbers<\/strong>. The exam expects you to know that SIGTERM is 15, SIGKILL is 9, and SIGHUP is 1. Know that the default signal for <code>kill<\/code> is SIGTERM.<\/li>\n<li><strong>Understand the difference between <code>kill<\/code>, <code>killall<\/code>, and <code>pkill<\/code><\/strong>. Particularly, <code>kill<\/code> takes a PID, <code>killall<\/code> takes an exact name, and <code>pkill<\/code> takes a pattern.<\/li>\n<li><strong>Know the nice value range<\/strong>. -20 to 19. Regular users can only increase nice values (lower priority). Root can set any value.<\/li>\n<li><strong>Understand job control syntax<\/strong>. <code>Ctrl+Z<\/code> to suspend, <code>bg<\/code> to background, <code>fg<\/code> to foreground, <code>&<\/code> to start in background, <code>jobs<\/code> to list.<\/li>\n<li><strong>Know <code>nohup<\/code><\/strong>. What it does, where its default output goes (<code>nohup.out<\/code>), and when you would use it.<\/li>\n<li><strong>Read ps output<\/strong>. You should be able to look at ps output and identify process states, the parent PID, CPU\/memory usage, and the controlling terminal.<\/li>\n<li><strong>Process states<\/strong>. Know what R, S, D, T, and Z mean. The exam might give you a scenario and ask what state a process is likely in.<\/li>\n<\/ol>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>For the LPIC-2, you will also need to understand cgroups, resource limits, and deeper systemd service management, which we touched on in Sections 8 and 9.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:heading -->\n<h2>Summary<\/h2>\n<!-- \/wp:heading -->\n\n<!-- wp:paragraph -->\n<p>Process management in Linux boils down to four activities: inspecting what is running, controlling how it runs, adjusting its priority, and terminating it when needed. The tools covered here give you complete control over every process on the system.<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:paragraph -->\n<p>For quick reference:<\/p>\n<!-- \/wp:paragraph -->\n\n<!-- wp:list -->\n<ul>\n<li><strong>Snapshot<\/strong>: <code>ps aux<\/code>, <code>ps -ef<\/code>, <code>ps -eo<\/code><\/li>\n<li><strong>Live monitoring<\/strong>: <code>top<\/code>, <code>htop<\/code>, <code>watch<\/code><\/li>\n<li><strong>Finding processes<\/strong>: <code>pgrep<\/code>, <code>pidof<\/code>, <code>\/proc<\/code><\/li>\n<li><strong>Priority<\/strong>: <code>nice<\/code>, <code>renice<\/code><\/li>\n<li><strong>Job control<\/strong>: <code>bg<\/code>, <code>fg<\/code>, <code>jobs<\/code>, <code>&<\/code>, <code>Ctrl+Z<\/code>, <code>nohup<\/code>, <code>disown<\/code><\/li>\n<li><strong>Signals<\/strong>: <code>kill<\/code>, <code>killall<\/code>, <code>pkill<\/code><\/li>\n<li><strong>Services<\/strong>: <code>systemctl<\/code>, <code>journalctl<\/code><\/li>\n<li><strong>Resource control<\/strong>: cgroups, <code>ulimit<\/code>, <code>systemd-cgtop<\/code><\/li>\n<\/ul>\n<!-- \/wp:list -->\n\n<!-- wp:paragraph -->\n<p>Master these tools and you will handle any process-related situation that comes up, whether on an exam or a production server at 3 AM.<\/p>\n<!-- \/wp:paragraph -->","protected":false},"excerpt":{"rendered":"<p>Every running program on a Linux system is a process. Whether it is the shell you are typing commands into, a web server handling thousands of requests, or a database crunching queries, it is all processes under the hood. Understanding how to inspect, control, prioritize, and terminate processes is a core sysadmin skill and a &#8230; <a title=\"Managing Linux Processes with ps, top, kill, bg and fg\" class=\"read-more\" href=\"https:\/\/computingforgeeks.com\/managing-linux-processes-commands\/\" aria-label=\"Read more about Managing Linux Processes with ps, top, kill, bg and fg\">Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":162763,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[299,47,50],"tags":[363,383],"class_list":["post-161439","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to","category-linux","category-linux-tutorials","tag-kill","tag-top"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/161439","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=161439"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/161439\/revisions"}],"predecessor-version":[{"id":162760,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/161439\/revisions\/162760"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/162763"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=161439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=161439"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=161439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}