I Killed Firefox From the Terminal — And It Changed How I Think About Linux

The ps Command

Firefox opened 47 windows at once.

I didn’t reach for the mouse.

I opened the terminal — and that split-second decision taught me more about Linux than weeks of reading documentation.

Let me show you exactly what I did, why it worked, and what it reveals about how Linux actually thinks.

The Incident

I was exploring RedHat’s RSS feed — curious Linux nerd moment — when I accidentally opened the file directly in Firefox instead of a feed reader. The browser went into a loop. Windows kept spawning. The system slowed down.

Normal people would click X forty-seven times, or worse, force-restart the machine.

I opened the terminal.

Step 1: Find the Process

ps aux | grep firefox

Output:

user    8585  45.2  8.1 2847392 334812 ?  Sl  14:23  3:12 /usr/lib/firefox/firefox
user    8612   0.0  0.0   6432   720 pts/0  S+  14:26  0:00 grep --color=auto firefox

Let’s break down what ps aux actually shows you:

Column Meaning USER Who owns the process PID Process ID — the unique number we need %CPU How much CPU it’s consuming %MEM Memory usage COMMAND What’s actually running

The important number here is the PID: 8585.

Notice the second line? That’s the grep command itself showing up. Ignore it — its PID is different and it'll disappear in a second anyway.

Step 2: Kill It

kill -9 8585

Boom. Firefox gone instantly.

But what does -9 actually mean?

Understanding Linux Signals

When you run kill, you're not "deleting" a process. You're sending it a signal — a message from the kernel.

Linux has 64 signals. Here are the ones you’ll actually use:

Signal Number Meaning SIGTERM 15 “Please stop when you’re ready” SIGKILL 9 “Stop. Now. No questions.” SIGHUP 1 “Reload your configuration” SIGSTOP 19 “Pause” SIGCONT 18 “Resume”

kill -15 8585   # Polite request to terminate
kill -9 8585    # Forced termination — no cleanup
kill -1 8585    # Reload config (useful for daemons)

Why did I use -9 instead of -15?

Because Firefox was frozen. A frozen process ignores SIGTERM — it can’t respond to polite requests. SIGKILL bypasses the process entirely and goes straight to the kernel. The kernel removes it from memory immediately.

Think of it this way:

• SIGTERM = “Hey, can you leave?”
• SIGKILL = The kernel physically removes the process from existence

A Smarter Way: pgrep and pkill

Typing ps aux | grep firefox works, but there's a cleaner approach:

# Find the PID without grep
pgrep firefox

# Kill by name directly - no PID needed
pkill firefox

# Kill forcefully by name
pkill -9 firefox

pkill combines the search and the kill into one command. Much cleaner.

Going Deeper: Where Does Linux Store Process Info?

Here’s what most tutorials skip:

Everything ps shows you comes from a special directory called /proc.

ls /proc/8585

Output:

cmdline  environ  fd  maps  mem  net  root  stat  status  ...

Every running process gets its own folder in /proc named after its PID. Inside that folder, Linux stores everything about that process — open files, memory maps, environment variables, and more.

Try this:

cat /proc/8585/status

You’ll see the process name, its state (running/sleeping/zombie), memory usage, and the user who owns it.

When the process dies, its /proc/[PID] folder disappears instantly. The kernel manages this automatically.

What This Moment Taught Me

1. The terminal gives you access to layers the GUI hides. A frozen Firefox is helpless against kill -9. The mouse is useless. The terminal talks directly to the kernel.

2. Every process is just a number. Once you understand PIDs, you stop seeing “programs” and start seeing processes. This is how SysAdmins think.

3. Linux is transparent by design. The /proc filesystem means nothing is hidden from you. Your system is an open book if you know where to look.

4. Instinct comes from practice, not memorization. I didn’t look up kill -9. It just came to me. That only happens when you use the terminal daily, not just when you study it.

Quick Reference

# See all running processes
ps aux

# Find a specific process
ps aux | grep firefox
pgrep firefox

# Kill by PID
kill -9 [PID]

# Kill by name
pkill -9 firefox

# List all available signals
kill -l

# Explore process details
ls /proc/[PID]
cat /proc/[PID]/status

Final Thought

I’m currently working toward my LPIC-1 certification. Days like this remind me that the best Linux lessons don’t come from textbooks — they come from moments when something breaks and you decide to fix it the right way.

The terminal isn’t just a tool. It’s a completely different way of seeing your system.

Next time something crashes on your machine — open the terminal first.

What was your first “I can’t believe I just did that from the terminal” moment? I’d love to hear it in the comments.