Free tools Windows power users keep installed
One-click scans. No signup required.
Linux process management starts with four complementary tools: ps gives a stable snapshot, top shows a changing live view, kill sends signals to processes or process groups, and systemctl controls services managed by systemd. The safest workflow is to observe first, identify ownership and scope, request a normal stop, and verify the result before escalating.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide explains what each tool actually controls, provides reusable commands, and shows when a service unit is a better target than an individual process.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe four tools at a glance
| Tool | View or target | Primary purpose | What the action means | Best fit |
|---|---|---|---|---|
ps |
Processes at a point in time | Produce a repeatable listing for inspection, filtering, or records | No control action; it only reports | Finding a PID, parent, owner, state, or command line |
top |
Continuously refreshed process display | Watch CPU, memory, load, and state as they change | Interactive monitoring; optional signals can be sent from the display | Diagnosing a spike or a process that changes over time |
kill |
A PID or process group | Send a selected signal | Requests or forces a process action, depending on the signal | Stopping a standalone process you have identified |
systemctl |
A systemd unit and its managed processes | Inspect and control service lifecycle | Changes a unit’s state and follows service-manager policy | Starting, stopping, restarting, or diagnosing a daemon |
A process is a running instance with a process ID (PID). A service is an operational concept represented by a systemd unit, commonly a .service unit. One service can create several processes, restart them, apply dependencies, and place them in a control group (cgroup). That difference determines whether a PID-level command or a unit-level command is appropriate.
Inspect a stable process snapshot with ps
The ps manual defines the command as reporting “a snapshot of the current processes.” The output is therefore a point-in-time observation, not a continuously updated dashboard. This makes it suitable for scripts, incident notes, and commands whose output must be compared later.
#1 Best Overall
List the processes you can see
ps
With no options, ps normally shows processes associated with your terminal. To display a broader system view, use:
ps -ef
The -e selection includes every process, while -f requests a full-format listing. Depending on the implementation and options, columns include the owner, PID, parent PID (PPID), start information, terminal, cumulative CPU time, and command.
Ask for exactly the fields you need
ps -p PID -o pid,ppid,user,stat,pcpu,pmem,cmd
Replace PID with a number. The -p selector limits the result to that process, and -o defines explicit columns. STAT is useful for a process state such as running, sleeping, stopped, or zombie; PCPU and PMEM show the process’s current CPU and memory percentages as reported by ps.
Find a command by name, then verify the result
ps -ef | grep '[a]pp-name'
The bracket pattern prevents the grep command itself from matching. Name matching can still find a wrapper, an unrelated command containing the same text, or a child process, so treat it as a lead. Confirm the PID, owner, PPID, executable, and full command line with a focused ps -p query before sending a signal.
Understand parent and child relationships
ps -eo pid,ppid,user,stat,cmd --forest
A PPID identifies the parent process. The relationship matters when a process is repeatedly recreated: the parent may be a supervisor, a service manager, a shell script, or another application. Killing a child without addressing its supervisor can produce a short-lived disappearance followed by a new PID.
Permissions and disappearing processes
Some processes hide command-line details or deny inspection to unprivileged users. Use elevated privileges only when your administrative role permits it, and understand the command before running it with sudo. A process can exit between the snapshot and a later command; a “no such process” result may simply mean the PID has already ended or been reused, so never assume an old PID still identifies the same program.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsMonitor changing behavior with top
The top manual describes a “dynamic real-time view” of running tasks. It repeatedly refreshes a summary and a task list, allowing you to see whether load, CPU use, memory use, or process state is changing rather than relying on one sample.
Start and narrow the display
top
Inside top, the exact key layout can vary by version, but common controls include:
P: sort the task list by CPU use.M: sort by memory use.1: show individual CPU lines rather than one aggregate line on implementations that support it.c: toggle between a short command name and the full command line.k: prompt for a PID and signal, allowing a signal to be sent from the monitor.q: quit.
Use top -p PID to watch a particular PID when supported by your implementation. Monitoring one process can reveal whether a suspected leak or CPU loop is persistent, intermittent, or already resolved.
Read the display without jumping to conclusions
The summary includes system load and memory information, while the task area reports per-process values. A high CPU percentage may be normal for a short compilation; sustained use, a growing resident memory value, or many processes in an uninterruptible state warrants further investigation. A single refresh is not evidence of a trend. Watch long enough to distinguish a transient burst from a persistent condition, then use ps to capture a stable record.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use top for observation, not as a substitute for service diagnosis
top tells you what tasks are doing now. It does not tell you the complete service policy, dependency graph, restart behavior, startup enablement, or recent journal messages. When the process belongs to a systemd unit, switch to systemctl for lifecycle decisions and use top to observe the effect.
Stop a standalone process with kill
The kill manual states: “The command kill sends the specified signal to the specified processes or process groups.” Despite its name, it is a signal interface, not an unconditional delete operation.
Request a normal termination first
kill PID
If you omit a signal, kill sends TERM (SIGTERM). TERM is a request for orderly termination: a cooperative program can close files, flush data, remove temporary state, and exit cleanly. Wait briefly, then verify:
ps -p PID -o pid,ppid,user,stat,cmd
If the command reports no matching process, the process has exited. If it remains, check whether it is still making progress and whether you have permission to signal it.
Recommended Free Tools
Choose a specific signal deliberately
kill -HUP PID
kill -INT PID
kill -STOP PID
kill -CONT PID
kill -KILL PID
- HUP is conventionally used by some daemons to reload configuration, but only when that program documents the behavior.
- INT resembles an interrupt, similar to pressing Ctrl-C in a terminal, and may be handled by the application.
- STOP pauses a process and cannot be caught by it; CONT resumes a stopped process.
- KILL (SIGKILL) cannot be caught or cleaned up by the target. It should be a last resort for an unresponsive process because the program cannot flush buffers or perform shutdown handlers.
You can write the numeric form, such as kill -15 PID, but signal names are clearer and avoid assumptions about platform-specific numbering.
Rank #4
Signal a process group only when you understand the scope
A process group can contain a command and its children. Group-oriented signaling can stop a whole foreground job, but an overly broad target can terminate unrelated work. Confirm the group ID and membership before using group syntax, and prefer a systemd unit for a service whose complete process tree is managed by systemd.
Why a process may not stop
- Insufficient permission: the process belongs to another user or a protected service.
- Uninterruptible sleep: a task waiting in the kernel, often for I/O, may not react until the wait ends; KILL cannot make every kernel wait complete instantly.
- Supervisor restart: a parent or service manager starts a replacement, giving the impression that the signal failed.
- Wrong PID: the original process exited and the number was later reused; re-run
psimmediately before acting.
Recognize when systemd and systemctl are the right layer
On systems that use it, systemd is the service manager. Its manual says that, when started as PID 1, it “acts as init system that brings up and maintains userspace services.” It models services and other resources as units with dependencies and states. systemctl is the control surface; its manual says it “may be used to introspect and control the state of the systemd system and service manager.”
Determine whether a PID belongs to a unit
systemctl status unit.servicesystemctl status PID
Replace unit.service with the actual unit name. On many systemd versions, asking for a PID can help identify its unit; if that form is unavailable, inspect the service status and compare its Main PID with ps. The status view commonly shows whether the unit is loaded, enabled, active, its main PID, recent log lines, and a cgroup process tree.
Use lifecycle operations for managed services
systemctl stop unit.service
systemctl restart unit.service
systemctl start unit.service
systemctl enable unit.service
systemctl disable unit.service
stop requests that the unit shut down according to its service definition. restart performs a stop followed by a start, which is useful after a configuration change when the service supports it. start activates a stopped unit. enable and disable change whether the unit is linked into boot-time targets; they do not, by themselves, start or stop a currently running service. Use enable --now or disable --now only when you intentionally want both the persistent setting and the immediate state changed.
Inspect unit state and dependencies
systemctl is-active unit.service
systemctl is-enabled unit.service
systemctl show unit.service
systemctl list-dependencies unit.service
These commands separate runtime state from boot policy and expose properties or dependencies that a PID listing cannot show. For failure context, inspect the unit’s journal:
Best Value
- New
- Mint Condition
- Dispatch same day for order received before 12 noon
- Guaranteed packaging
- No quibbles returns
journalctl -u unit.service
Use the journal output to find configuration errors, permission failures, dependency problems, or repeated crash-and-restart cycles before deciding whether another restart is safe.
Control the processes inside a unit when needed
systemctl kill --kill-who=main unit.service
systemctl kill --kill-who=control unit.service
systemctl kill --kill-who=cgroup unit.service
systemctl kill --kill-who=all unit.service
The unit-level kill operation can select the main process, control processes, the unit’s cgroup, or all of those categories. This preserves the service-manager context and makes the intended scope explicit. A cgroup-wide action can affect workers and helper processes, so inspect status first and choose the narrowest scope that solves the problem. A plain kill PID may leave workers behind or trigger an automatic restart, while systemctl stop follows the unit’s configured termination and dependency rules.
A safe investigation and shutdown workflow
- Capture a baseline. Run
ps -effor a broad snapshot orps -p PID -o pid,ppid,user,stat,pcpu,pmem,cmdfor a focused record. - Watch the behavior. Start
top, sort by CPU or memory, and narrow to the suspected PID when the issue changes over time. - Identify ownership and scope. Confirm the user, executable, parent, process group, and whether a systemd unit owns the process.
- Select the control layer. Use
kill PIDfor an independently launched process. Usesystemctl statusand a unit operation for a managed service. - Request an orderly stop. Send TERM or run
systemctl stop unit.service. Allow the program its configured shutdown time. - Verify. Re-run
ps, checktop, and inspectsystemctl statusif a unit is involved. - Escalate narrowly. If the process is truly unresponsive, choose a stronger signal or an explicitly scoped
systemctl kill. Record what you targeted and why. - Check for recurrence. A replacement PID indicates a supervisor or restart policy. Examine the unit status, dependencies, and journal instead of repeatedly killing each new PID.
Common mistakes and safer alternatives
Killing the first matching name
A name can match several unrelated processes. Use a full command line, owner, PPID, and start context to confirm identity. For repeated automation, select by a documented PID file, unit name, or other explicit contract rather than an unqualified text match.
Using SIGKILL as the first response
KILL prevents cleanup and can leave corrupted or incomplete application state. TERM followed by verification is the normal sequence; escalation is justified only when the process does not respond or a documented emergency procedure requires it.
Stopping a service with kill and expecting it to stay down
Systemd or another supervisor may restart a service after its process exits. Stop the unit to change its managed state, then inspect Restart=-related behavior and recent journal entries if it returns.
Confusing stop with disable
systemctl stop changes the current runtime state. systemctl disable changes boot-time activation links. Decide whether you need an immediate shutdown, a persistent boot-policy change, or both.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Assuming top is a historical log
top shows a live display and is not a durable record. Save a deliberate ps listing, journal output, or other approved diagnostic evidence when you need to document what happened.
Choosing the right command
| Question | Recommended first command | Reason |
|---|---|---|
| What processes exist right now? | ps -ef |
Stable, scriptable snapshot |
| Which process is consuming resources over time? | top |
Dynamic view with CPU and memory sorting |
| What is this PID’s owner, parent, and state? | ps -p PID -o pid,ppid,user,stat,pcpu,pmem,cmd |
Focused identity and state data |
| How do I ask an independent process to exit? | kill PID |
Sends TERM by default |
| How do I stop a daemon and its managed lifecycle? | systemctl stop unit.service |
Acts on the unit rather than one PID |
| Why did a service fail or come back? | systemctl status unit.service and journalctl -u unit.service |
Shows unit state, restart context, and logs |
Practical safety checklist
- Confirm the PID immediately before signaling it.
- Check the user and command line so you do not stop a similarly named process.
- Prefer TERM and verify before using KILL.
- Use a unit operation when systemd owns the service.
- Choose the smallest process scope that solves the problem.
- Expect permission errors and obtain authorization rather than bypassing them casually.
- Record the command, target, signal or unit operation, and observed result for incident follow-up.
Further reading on command references
Linux man pages are concise reference documents. Their brevity is useful once you understand the concepts, but newcomers should pair the syntax with an explanation of process identity, signals, units, and failure modes. On any installed system, run man ps, man top, man kill, man systemd, and man systemctl to see options supported by that distribution and version.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




