Today's Topic

Linux Basics

As an L2 engineer, you will live inside Linux servers every day. You won't click buttons — you'll type commands. Today you learn the 6 commands you'll use the most.

grep tail vi top df free

01 The Simple Idea First

Real-life Analogy

Think of a Linux server like a big office building with no windows or screens on the doors. You can't just click around and explore. You have to type exactly what you want and the building responds.

Want to find a specific file? Type it. Want to see who's using all the electricity? Type it. Want to read what's inside a file? Type it. The commands today are your master keys to navigate and investigate any Linux server.

Why do L2 engineers need Linux commands?

When a payment fails or an API goes down, the answer is almost always inside a log file on a Linux server. You need to connect to that server, find the right log file, and search through it for the error. All of this is done through these commands — no graphical interface, just the terminal.

Master these 6 commands and you can investigate almost any issue on a Linux server confidently.

02 The 6 Commands — Syntax, Use & Examples

grep

"Find a word inside a file — like Ctrl+F for the terminal"

What it does: grep searches inside a file and shows you only the lines that contain the word you're looking for. If a log file has 50,000 lines, grep instantly pulls out the 10 lines with the word "ERROR". This is your most used command as L2.

Syntax

grep [options] "search_word" filename

# Options you'll use most:
-i → ignore uppercase/lowercase
-n → show line numbers
-r → search inside all files in a folder
-c → count how many lines matched
-A 5 → also show 5 lines AFTER the match (context)

Command	What it does
grep "ERROR" app.log	Find all lines with the word ERROR in app.log
grep -i "error" app.log	Same but ignores upper/lowercase — finds ERROR, Error, error
grep -n "FAILED" payments.log	Find FAILED and show which line number it's on
grep -c "timeout" app.log	Count how many times "timeout" appears in the file
grep -r "ERROR" /var/logs/	Search for ERROR inside every file in the /var/logs folder
grep -A 5 "Exception" app.log	Find "Exception" and also show 5 lines after it — gives context

tail

Live View

"Watch a log file update in real time — like watching live TV"

What it does: tail shows you the last few lines of a file. But the real power is tail -f — this keeps the file open and shows new lines as they are added. When something is happening live on the server right now, tail -f lets you watch it happen in real time.

Syntax

tail [options] filename

# Options you'll use most:
-n 50 → show last 50 lines
-f → follow the file live (keeps updating)
-f -n 100 → show last 100 lines AND keep following live

Command	What it does
tail app.log	Show the last 10 lines of app.log
tail -n 50 app.log	Show the last 50 lines
tail -f app.log	Watch the log file live — new lines appear as they happen
tail -f -n 100 app.log	Show last 100 lines and keep watching live

💡 Pro tip: Combine tail and grep together: tail -f app.log | grep "ERROR" — this watches the live log but only shows you ERROR lines. Very useful during a live incident.

Editor

"Open and edit files directly on the server — like Notepad for Linux"

What it does: vi is a text editor built into almost every Linux server. You use it to open, read, and edit files — like config files or scripts. It feels weird at first because it has two modes: reading mode (you can scroll but not type) and editing mode (you can type and change things).

Syntax + Controls

vi filename # open a file

# Once inside vi:
i → press i to enter EDIT mode (now you can type)
Esc → press Esc to go back to READ mode
:w → save the file
:q → quit vi
:wq → save AND quit (most common)
:q! → quit WITHOUT saving (if you made a mistake)
/word → search for a word inside the file
n → jump to next match after searching

Command	What it does
vi config.properties	Open a config file to read or edit it
vi /etc/hosts	Open the server's hosts file
/ERROR then press n	Search for ERROR inside vi and jump through each match
:wq	Save changes and exit — the most used vi command
:q!	Exit without saving — use this if you opened the wrong file

⚠️ Be careful with vi on PROD servers. Always press Esc first before doing anything. Never type randomly — you might accidentally edit a critical config file.

top

Performance

"See what's happening on the server right now — like Task Manager"

What it does: top shows you a live view of your server's health — which processes are running, how much CPU each is using, how much memory is being used, and whether the server is overloaded. It refreshes every few seconds automatically.

Syntax + What You See

top # just type this and press Enter

# What you'll see on screen:
%CPU → how much of the processor each process is using
%MEM → how much memory (RAM) each process is using
PID → the ID number of each running process
COMMAND → the name of the process (e.g. java, mysql, nginx)

# Controls while inside top:
q → quit top
k → kill a process (enter PID number when asked)
P → sort by CPU usage (highest first)
M → sort by Memory usage (highest first)

What you see	What it means
java 97.3 %CPU	The Java app is eating almost all CPU — something is wrong with it
load average: 0.5	Server is relaxed. Load above 1.0 per CPU core means it's stressed
Mem: 95% used	Server is almost out of RAM — things will start crashing soon
zombie process	A process that finished but didn't close properly — usually harmless but worth noting

Disk

"Check how full your hard drive is — like checking storage on your phone"

What it does: df shows you the disk space on the server — how much is total, how much is used, and how much is free. When a disk fills up to 100%, the server stops writing any new data — logs stop, transactions fail, everything breaks. You need to check this regularly.

Syntax

df -h # -h means human readable (shows GB/MB not just numbers)

# Sample output:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 47G 3G 94% /
^^^
94% full — WARNING! Clean up soon

Command	What it does
df -h	Show all disks with sizes in GB/MB — easy to read
df -h /	Check only the main root disk space
df -h /var	Check disk space in the /var folder (where logs usually live)

⚠️ Rule of thumb: Above 80% = Warning. Above 90% = Act now. At 100% = Everything breaks. The most common cause of full disks is old log files that were never cleaned.

free

Memory

"Check how much RAM is available — like checking your phone's RAM"

What it does: free shows you the RAM (memory) situation on the server — how much total memory exists, how much is being used, and how much is free. If RAM runs out, the server starts using disk as backup memory (called swap) which is much slower, causing everything to lag or crash.

Syntax

free -h # -h means human readable (GB/MB)

# Sample output:
total used free shared buff available
Mem: 16G 14G 2G 300M 1G 1.5G
Swap: 4G 3G 1G
^^^
Swap being used = RAM is nearly full, server is struggling

Command	What it does
free -h	Show RAM and swap usage in human readable format
free -h -s 5	Refresh memory stats every 5 seconds (live view)

💡 Key thing to watch: If the Swap row shows high usage, it means RAM is nearly full and the server is struggling. This explains slow performance even when CPU looks normal.

03 Hands-on Lab — Search Error Logs

Scenario: Client says payments are failing since 2 PM

You SSH into the payment server. Your job: find out what errors appeared around 2 PM in the logs. Here's exactly what you type, step by step.

🔬 Lab: Investigating a Payment Failure Payment Server · PROD

Check if the server has enough disk space first

Before anything else — make sure the server isn't full. A full disk can cause all kinds of failures.

df -h → /dev/sda1 50G 38G 12G 76% / ← OK, still has space

Check memory — is the server running low on RAM?

A memory-starved server causes slow responses and transaction failures.

free -h → Mem: 16G total, 9G used, 7G free ← OK, plenty of RAM

Check what processes are eating resources right now

See if any process is hogging CPU or memory.

top → java process at 88% CPU ← Suspicious! Payment app is working very hard

Go to the log folder and search for errors around 2 PM

Use grep to find all ERROR lines in the payment log file.

grep -n "ERROR" /var/logs/payment-app.log

→ Line 4821: [14:02:15] ERROR - DB_CONNECTION_TIMEOUT
→ Line 4823: [14:02:16] ERROR - Transaction TXN-9821 failed
→ Line 4830: [14:02:18] ERROR - DB_CONNECTION_TIMEOUT

Get more context around the error — what happened before and after?

Use -A to see 5 lines after each error for more detail.

grep -A 5 "DB_CONNECTION_TIMEOUT" /var/logs/payment-app.log → Shows full stack trace — confirms database connection pool exhausted

Watch the log live to see if errors are still happening now

Use tail -f combined with grep to watch only error lines in real time.

tail -f /var/logs/payment-app.log | grep "ERROR" → New errors still appearing every few seconds ← Issue is ongoing

04 Quick Cheat Sheet

⌨️ All 6 Commands at a Glance

grep "ERROR" file.logFind ERROR in a log file

grep -r "word" /folder/Search all files in a folder

tail -f app.logWatch a log file live

tail -n 100 app.logShow last 100 lines

vi filenameOpen a file to read/edit

:wq / :q!Save+quit / quit without saving

topLive view of CPU and memory usage

top then press P or MSort by CPU or Memory

df -hCheck disk space — is it full?

df -h /varCheck space in logs folder

free -hCheck RAM — is it running low?

tail -f log | grep "ERR"Watch live errors only — most useful combo

05 Real L2 Scenarios

Alert fires: "Payment service down." You SSH in, run top — one Java process is at 99% CPU. That's your problem. The app is stuck in a loop. You note the PID, raise a P1 ticket, and escalate to L3 to restart the process safely.

Client says "logs stopped writing since this morning." You run df -h — disk is at 100%. Log files filled it up. You need to archive or delete old logs to free space. After clearing, logs start writing again immediately.

Client says "transaction TXN-5541 failed, please check." You run grep "TXN-5541" payment.log — you find exactly the lines related to that transaction and can see the exact error message and timestamp. Job done in 10 seconds.

You need to check a config file to see what database the app is pointing to. You run vi application.properties, press /database to search, find the DB connection string, read it, then press :q! to exit without touching anything.

✅ Week 2 · Day 1 Outcomes — Can You Do This?

Use grep to search for any word inside a log file and filter results
Use tail -f to watch a log file updating live during an incident
Combine tail and grep to watch only error lines in real time
Open, read, and safely exit a file using vi without breaking anything
Use top to identify which process is eating CPU or memory on a server
Use df -h to check disk space and know when to raise an alert
Use free -h to check RAM usage and understand what swap usage means
Complete the full log investigation lab — find errors in a payment log step by step