DEV Community: Sreekanth Kuruba

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

Sreekanth Kuruba — Tue, 04 Aug 2026 06:18:32 +0000

Most Linux problems aren't actually difficult.

They're difficult because they're often debugged in the wrong order.

Many beginners immediately:

Restart services randomly
Run commands without a plan
Change configurations before understanding the problem
Guess instead of observing

Experienced engineers do something different.

They follow a structured troubleshooting process.

This article isn't about learning new Linux commands.

It's about knowing when and why to use the commands you've already learned throughout this Linux Beginner Series.

Think of it as putting everything together into one practical troubleshooting workflow that's used in real Linux and DevOps environments.

Quick Troubleshooting Workflow

Observe
   ↓
Check System Health
   ↓
Identify Problem Type
   ↓
Read Logs
   ↓
Verify Service
   ↓
Check Network
   ↓
Check Disk
   ↓
Recent Changes
   ↓
Find the Root Cause
   ↓
Apply the Fix

Keep this workflow in mind as you read through the guide.

Step 0: Observe Before You Change Anything

Before running a single command, pause for a moment.

Ask yourself:

What exactly is broken?
When did the issue start?
Is everyone affected or only some users?
Is the problem constant or intermittent?
What changed recently?

Many troubleshooting sessions become longer because people try to fix the problem before they understand it.

Good troubleshooting begins with observation, not commands.

Step 1: Check Overall System Health

Your first goal is to understand the overall health of the system—not to fix anything yet.

Useful commands:

uptime
free -h
top

Look for:

High load average
High CPU usage
Low available memory
Signs that the server is under heavy load

At this stage, you're only gathering evidence.

A quick system health check often tells you where to investigate next.

Step 2: Identify the Type of Problem

Before diving deeper, classify the issue.

Problem Type	Common Symptoms	First Commands to Check
CPU	Slow system, high CPU usage	`top`, `htop`
Memory	Applications crashing, OOM kills	`free -h`
Disk	"No space left on device"	`df -h`, `du -sh`
Network	Connection failures	`ping`, `curl`, `ip a`
Service	Service unavailable	`systemctl status`
Application	Errors or exceptions	Application logs

Classification narrows your investigation instead of jumping between unrelated commands.

A well-classified problem is already half solved.

Step 3: Read the Logs

Logs are usually the most reliable source of information during troubleshooting.

System logs:

journalctl -xe

Specific service:

journalctl -u nginx

Traditional log files:

tail -f /var/log/nginx/error.log

Search for errors:

grep -i error /var/log/syslog

For large log files, use less to navigate comfortably instead of opening the entire file at once.

💡 Tip: Replace nginx with the service you're troubleshooting, such as sshd, docker, or apache2.

Logs often tell you what failed.

Your job is to discover why it failed.

Step 4: Verify the Service

Never assume a service is healthy just because the application isn't responding.

Check the service status:

systemctl status nginx

Verify the running process:

ps aux | grep nginx

A service can be running while still failing to serve requests correctly.

For example:

The process may be running.
The application may have failed during startup.
The service may be unable to connect to its database.
Configuration errors may prevent it from serving requests.

Always verify the service before moving on to other areas.

Step 5: Check the Network

If the service looks healthy, verify connectivity.

Useful commands:

ping <host>
curl -I http://localhost:8080
ip a
ss -tuln

These commands help answer questions like:

Can the server reach other systems?
Is the application listening on the expected port?
Is the network interface configured correctly?

Many "application issues" are actually network or DNS problems.

Step 6: Check Disk Space and Inodes

Disk-related problems are among the most common causes of Linux issues.

Check disk usage:

df -h

Check inode usage:

df -i

Find large directories:

du -sh /* 2>/dev/null | sort -hr

A full disk—or exhausted inodes—can prevent applications from:

Writing log files
Creating temporary files
Saving uploaded data
Starting correctly

Even if CPU and memory look healthy, disk issues can bring an application down.

Step 7: Look for Recent Changes

Many production issues are caused by something that recently changed.

Review recent logs:

journalctl --since "1 hour ago"

Check recent logins:

last -10

Ask yourself:

Was there a recent deployment?
Was a configuration changed?
Was a package updated?
Did anyone restart the service?

If you need to locate a configuration file, use tools like find or whereis.

Before making major configuration changes, consider creating a backup with tar so you can easily restore the original if needed.

Looking for recent changes often shortens the investigation dramatically.

Step 8: Find the Root Cause, Not Just the Symptom

Finding an error doesn't always mean you've found the real problem.

For example:

A web application crashes.

The logs show write failures.

You check the disk.

The disk is full.

The application wasn't the real problem.

The full disk was.

Always ask yourself:

"Is this the root cause, or just another symptom?"

This habit separates troubleshooting from guessing.

A Simple Troubleshooting Workflow

Whenever something breaks, follow the same sequence:

Observe the problem
        ↓
Check system health
        ↓
Identify the problem type
        ↓
Read the logs
        ↓
Verify the service
        ↓
Check the network
        ↓
Check disk space
        ↓
Look for recent changes
        ↓
Find the root cause
        ↓
Apply the fix

Following the same workflow every time reduces guesswork and speeds up troubleshooting.

A Real-World Example

Imagine a user reports:

"The website is down."

Instead of restarting Nginx immediately:

Check whether the service is running.
Read the service logs.
Notice repeated "No space left on device" errors.
Run:

df -h

Discover the disk is full.
Free up disk space.
Restart the service if necessary.

The restart wasn't the solution. Finding the root cause was.

Common Beginner Mistakes

Avoid these habits:

Restarting services without checking logs
Ignoring CPU, memory, or disk usage
Running random commands without a plan
Assuming the first error is the real cause
Skipping recent changes

Good troubleshooting isn't about memorizing commands.

It's about following a consistent process.

Final Thoughts

Linux troubleshooting isn't about knowing hundreds of commands.

It's about asking the right questions in the right order.

Commands help you collect evidence.

A structured process helps you solve the problem.

The faster you narrow down the problem, the faster you'll reach the root cause.

That's the mindset experienced engineers develop over time.

Start with a simple process.

Practice it consistently.

You'll spend less time guessing and more time solving problems.

Congratulations!

If you've followed this Linux Beginner Series from the beginning, you've built a solid foundation in:

Linux basics
Filesystem structure
Users & Permissions
Processes
Disk usage
Networking
Logs
Package management
Finding files & text
Viewing files efficiently
File compression
Troubleshooting workflow

That's no longer just a collection of Linux commands.

It's a practical foundation for understanding how Linux systems work and how to troubleshoot them with confidence.

Remember:

Good engineers don't memorize every command.

They know how to investigate problems, gather evidence, and find the root cause.

The best way to improve at troubleshooting is simple:

Break things in a safe environment.
Fix them.
Learn from them.

That's where real learning happens.

Thank you for following this Linux Beginner Series!

Your Turn

What's one Linux troubleshooting lesson you learned the hard way?

Share your experience in the comments—your story might help another beginner avoid the same mistake.

Happy learning!

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Sreekanth Kuruba — Thu, 30 Jul 2026 06:44:14 +0000

Working with files in Linux isn't just about creating and editing them.

Sometimes you need to:

Archive multiple files into one
Compress files to save disk space
Share files with others
Create backups

Linux provides several tools for this, each with a different purpose.

Let's simplify them.

What is File Compression?

File compression reduces the size of a file.

Benefits:

Saves disk space
Faster file transfers
Easier backups
Reduces bandwidth usage

Example:

A 100 MB log file might become a much smaller compressed file, depending on its contents.

Archive vs Compression

Many beginners think they're the same.

They are not.

Archive

Combines multiple files into a single file.

Example:

photos/
docs/
notes.txt

↓

backup.tar

Compression

Reduces the size of a file.

Example:

backup.tar

↓

backup.tar.gz

👉 tar archives files. gzip compresses them.

1. Create an Archive with tar

tar -cvf backup.tar Documents/    #Create an archive
tar -tvf backup.tar               #View archive contents
tar -xvf backup.tar               #Extract an archive

Options:

c → Create
v → Verbose (show progress)
f → File name
x → Extract

Best for:

Backups
Bundling multiple files
Moving folders

2. Compress with gzip

Compress a file:

gzip file.txt          # Creates file.txt.gz
# Result
file.txt.gz
gunzip file.txt.gz     # decompress
gzip -k file.txt       # Keep original file

Best for:

Log files
Large text files
Saving disk space

3. Archive and Compress Together

Most common command:

# Create compressed archive
tar -czvf backup.tar.gz Documents/
# Extract
tar -xzvf backup.tar.gz

Options:

z → Use gzip compression

👉 This is one of the most common backup commands in Linux.

4. Working with ZIP Files

# Create ZIP
zip -r project.zip project/
# Extract
unzip project.zip
# List contents
unzip -l project.zip

Best for:

Sharing files with Windows users
Cross-platform compatibility

5. Compare the Tools

Tool	Purpose	Best For
`tar`	Archive files	Backups
`gzip`	Compress files	Saving space
`tar + gzip`	Archive and compress	Linux backups
`zip`	Archive and compress	Sharing files across operating systems

Real-World Example

You need to back up a website before making changes.

# Create backup
tar -czvf website-backup.tar.gz /var/www/html
# Restore later if needed
tar -xzvf website-backup.tar.gz

This is a common practice before upgrades, migrations, or configuration changes.

Common Beginner Mistakes

Thinking tar compresses files by itself
Forgetting -z when creating .tar.gz archives
Compressing files that are already compressed (like .jpg or .mp4)
Extracting archives into the wrong directory
Deleting backups before verifying they can be restored

Simple Mental Model

Think of it like packing for a trip:

tar → Put all your clothes into one suitcase.
gzip → Compress the suitcase to make it smaller.
tar.gz → Pack everything into one suitcase and compress it.
zip → A suitcase that's easy to share with almost any operating system.

Summary

In this guide you learned:

What file compression is
Archive vs. compression
Creating archives with tar
Compressing files with gzip
Creating .tar.gz archives
Working with ZIP files
Common beginner mistakes

Why This Matters

File compression is used every day by:

Linux administrators
DevOps engineers
Cloud engineers
Developers

Whether you're creating backups, transferring files, or saving disk space, understanding these tools is an essential Linux skill.

Congratulations!
You’ve now covered the essential Linux fundamentals.

In the next and final post, we’ll combine everything from this series into a practical troubleshooting workflow you can use to diagnose Linux issues with confidence.

Next Post

Linux Troubleshooting Flow for Beginners

Question for You

Which compression format do you use most often: .tar.gz or .zip? And in what situation?

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Sreekanth Kuruba — Tue, 21 Jul 2026 06:38:18 +0000

Introduction

Finding a file is only half the job.

The next step is reading it.

Whether it's a configuration file, a log, or a text document, Linux provides several commands to view files efficiently.

Each command has a different purpose.

Knowing which one to use can save time and make troubleshooting much easier.

Let's simplify them.

Why Not Just Use cat for Everything?

Many beginners learn:

cat filename

Then use it for every file.

It works...

Until the file has 50,000 lines.

Linux provides better tools depending on what you're trying to do.

1. View the Entire File with cat

The cat command displays the complete contents of a file.

Example:

cat config.txt
cat file1.txt file2.txt     # Combine files
cat > notes.txt             # Create new file

Best for:

Small files
Quick checks
Combining files

2. Read Large Files with less

Large files are difficult to read with cat.

Use:

less /var/log/syslog
less /etc/nginx/nginx.conf

Useful shortcuts:

Space → Next page
b → Previous page
/text → Search
q → Quit

Best for:

Configuration files
Large logs
Documentation

3. View the Beginning with head

Sometimes you only need the first few lines.

head file.txt
head -20 file.txt          # First 20 lines

Useful for:

Checking file headers
Previewing files

4. View the End with tail

Need the latest log entries?

tail file.txt
tail -20 file.txt          # Last 20 lines

Perfect for log files.
Checking recent changes.

5. Monitor Files Live with tail -f

One of the most-used Linux troubleshooting commands.

tail -f /var/log/nginx/error.log
tail -f app.log

As new lines are written, they appear instantly.

Stop with:

Ctrl + C

Useful for:

Monitoring logs
Watching application output
Debugging services

6. Count with wc

Want to know how big a file is?

wc file.txt
wc -l file.txt             # Count only lines
wc -w file.txt             # Count words
wc -m file.txt             # Count characters

Useful for:

Scripts
Reports
Log analysis

Real-World Example

An application isn't starting.

First, check the configuration file:

# First, check the configuration file:
less /etc/nginx/nginx.conf

# Monitor the error log:
tail -f /var/log/nginx/error.log

# Need to know how many errors occurred?
grep -i error app.log | wc -l

This is a common workflow when troubleshooting Linux systems.

Common Beginner Mistakes

Using cat for huge files
Forgetting less supports searching
Not using tail -f for live logs
Thinking head and tail only work with 10 lines

Simple Mental Model

Think of these commands like reading a book.

Command	Think of it as...
`cat`	Read the whole book
`less`	Read page by page
`head`	Read the first page
`tail`	Read the last page
`tail -f`	Watch new pages being written
`wc`	Count pages, words, or characters

Summary

In this guide you learned:

cat → View complete files
less → Read large files
head → View the beginning
tail → View the end
tail -f → Monitor files live
wc → Count lines, words, and characters

Why This Matters

Configuration files and logs are everywhere in Linux.

Knowing how to read them efficiently is an essential skill for developers, system administrators, and DevOps engineers.

The right command can save time and make troubleshooting much easier.

Next Post

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Question for You

Which command do you use the most when reading files in Linux?

cat
less
tail
Or something else?

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Sreekanth Kuruba — Tue, 14 Jul 2026 03:03:02 +0000

One of the most common questions Linux beginners ask is:

“Where is this file?”
“How do I find a specific error in logs?”
“Where is this command installed?”

Linux has powerful tools to answer these questions quickly.

In this guide, you’ll learn the most useful search commands.

Finding Files vs Searching Text

These are two different tasks:

Finding files = Locating a file or directory on the system → find
Searching text = Looking for words inside files → grep

1. Find Files with `find`

# Find a specific file
find /home -name "nginx.conf"

# Search entire system (ignore permission errors)
find / -name "*.log" 2>/dev/null

# Find only directories
find . -type d

# Find only files
find . -type f

# Find files larger than 100MB
find / -type f -size +100M 2>/dev/null

Useful for:

Finding configuration files
Locating log files
Finding large files
Searching project directories

Best Tip: Always try to narrow the search path instead of searching from / whenever possible.

2. Search Text Inside Files with `grep`

# Search for a word
grep error app.log

# Case insensitive search
grep -i error app.log

# Search recursively in directory
grep -r "database" /etc/

# Show line numbers
grep -n "listen" nginx.conf

# Count matches
grep -c "failed" auth.log

Useful for:

Searching logs
Finding configuration values
Looking for error messages
Debugging applications

3. Find Executable Location with `which`

which python3
which docker
which nginx

Shows the full path of the command that will be executed.

Useful for:

Finding executable locations
Checking which version of a command Linux will run
Verifying software installation

4. Find Program Files with `whereis`

whereis nginx
whereis python3

It can show:

Binary location
Source files (if available)
Manual pages

Useful when you want to know where a program and its documentation are stored.

Bonus: Fast File Search with `locate`

locate nginx.conf

Much faster than find because it uses a database.

If it doesn't return recent files, Update database:

sudo updatedb

Note: locate may not be installed by default on every Linux distribution.

Real-World Troubleshooting Example

Nginx is not starting.

# Find config file
find /etc -name nginx.conf 2>/dev/null

# Search for errors in logs
grep -i error /var/log/nginx/error.log

# Check executable
which nginx

# See all related files
whereis nginx

This is a common workflow during Linux troubleshooting.

Common Beginner Mistakes

Using find / instead of a specific directory
Forgetting 2>/dev/null when searching the whole system
Confusing find with grep
Not knowing the difference between which and whereis
Forgetting that locate may require an updated database

Simple Mental Model

Command	Use For
`find`	Locate files and directories
`grep`	Search text inside files
`which`	Find executable path
`whereis`	Find program + docs
`locate`	Fast filename search

Summary

In this guide you learned:

How to find files with find
How to search text with grep
How to locate commands with which and whereis
How to perform fast filename searches with locate

Next Post:

Viewing Files in Linux (cat, less, head, tail & wc)

Question for You

Which command do you use most while troubleshooting — find, grep, or something else?

Linux Package Management Explained Simply (apt, dnf, yum & rpm)

Sreekanth Kuruba — Tue, 07 Jul 2026 03:13:00 +0000

Quick Note

In my previous article, I mentioned that Linux Troubleshooting Flow for Beginners would be the final post in this series.

While preparing it, I realized there were a few practical Linux skills every beginner should learn first. These topics will make the troubleshooting guide much easier to understand and follow.

Before we wrap up the series, we'll cover:

Package Management
Finding Files & Text
Viewing Files Efficiently
File Compression

Then we'll bring everything together in the final Linux Troubleshooting Flow for Beginners.

Introduction

Installing software on Linux is very different from Windows.

On Windows, you usually download an .exe installer.

On Linux, software is typically installed and managed using package managers.

This is one of the most practical skills every Linux beginner should learn early.

What is a Package?

A package is a ready-to-install bundle that contains:

The main program
Required libraries
Configuration files
Documentation

Examples: nginx, git, docker, curl, vim

Think of a package as a ready-to-install software box.

What is a Package Manager?

A package manager is a tool that installs, updates, removes, and manages software packages.
Instead of downloading software manually, you simply run a command.

Example:

sudo apt install git

The package manager automatically:

Downloads packages from trusted repositories
Install required dependencies automatically
Upgrade installed software
Removes them cleanly

Instead of manual downloading, you just run one command.

Why Use a Package Manager?

Without package managers, you would have to:

Search for software manually
Download files from websites
Install dependencies yourself
Update each application separately

Package managers automate all of this.

What is a Repository?

Package managers download software from repositories.

A repository is a trusted online collection of software packages maintained by your Linux distribution.

Instead of downloading software from random websites, Linux installs it securely from these repositories.

Common Package Managers

Distribution	Package Manager	Low-level Tool
Ubuntu / Debian	`apt`	`dpkg`
Fedora / RHEL / Rocky	`dnf`	`rpm`
Older RHEL / CentOS	`yum`	`rpm`

Most Ubuntu users will use apt, while Fedora and modern RHEL-based systems use dnf.

Most Useful Commands

1. Update Package List

Before installing software, update the package list.

sudo apt update          # Ubuntu/Debian
sudo dnf check-update    # Fedora/RHEL

Note: apt update does not upgrade installed packages.

2. Upgrade Installed Packages

sudo apt upgrade   #Ubuntu/Debian
sudo dnf upgrade   #Fedora/RHEL

Installs the latest available versions of your installed packages.

3. Install a Package

sudo apt install nginx   #Ubuntu/Debian
sudo dnf install nginx   #Fedora/RHEL

Example packages:

sudo apt install git
sudo apt install curl
sudo apt install vim

4. Remove a Package

sudo apt remove nginx    #Ubuntu/Debian
# Remove package and configuration files
sudo apt purge nginx     
sudo dnf remove nginx    #Fedora/RHEL

5. Search for Packages

apt search docker    #Ubuntu/Debian
dnf search docker    #Fedora/RHEL

Useful when you're unsure of the exact package name.

6. View Package Information

apt show nginx    #Ubuntu/Debian
dnf info nginx    #Fedora/RHEL

Shows details such as:

Version
Description
Dependencies
Package size

7. List Installed Packages

apt list --installed   #Ubuntu/Debian
dnf list installed     #Fedora/RHEL

Useful for verifying whether software is already installed.

Low-Level Tool: rpm

The rpm command works directly with RPM package files.

rpm -q nginx          # Check if installed
rpm -qi nginx         # Detailed info

Usually you don't need to use rpm directly. On RPM-based systems, dnf handles package installation and dependencies for you.

Common Beginner Mistakes

Running apt upgrade without apt update first
Confusing apt update with apt upgrade
Installing software from random websites instead of official repositories
Forgetting to use sudo
Removing important system packages

Simple Mental Model

Think of a package manager like an App Store for Linux:

Package = App
Repository = App Store
Package Manager = Installer + Updater

Summary

In this guide you learned:

What packages and package managers are
Basic package management commands using apt and dnf
Basic package management commands
Common mistakes to avoid

Why This Matters

Package management is a daily task for:

Linux administrators
DevOps engineers
Cloud engineers
Developers

If you know how to manage packages, setting up and maintaining Linux systems becomes much easier.

Next Post:

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Linux Logs Explained Simply

Sreekanth Kuruba — Tue, 30 Jun 2026 03:22:27 +0000

post: 7

When something breaks in Linux, experienced engineers don’t guess.

They check the logs.

👉 Logs are the “black box recorder” of a Linux system.

They tell you:

what happened
when it happened
why it failed

If you can read logs properly, you can debug almost anything.

What Are Logs?

Logs are records of system and application activity.

Linux constantly records:

System events
Errors
User activity
Application behavior

Linux constantly records:

Where are Logs Stored?

Most Linux logs are stored inside:

/var/log

Check logs directory:

cd /var/log
ls

This is the first place DevOps engineers check during system issues.

Important Log Files

Log File	Purpose	Command to View
`/var/log/syslog`	General system messages	`tail /var/log/syslog`
`/var/log/auth.log`	Login attempts & authentication	`tail /var/log/auth.log`
`/var/log/kern.log`	Kernel & hardware messages	`dmesg` or `tail /var/log/kern.log`
`/var/log/nginx/error.log`	Web server errors (Nginx)	`tail /var/log/nginx/error.log`
`/var/log/dmesg`	Boot and hardware logs	`dmesg`

/var/log/apache2/ -> Apache logs

These logs help you identify system, security, and application-level issues.

View Logs

Using cat

cat /var/log/syslog

Good for small files.

Using less

less /var/log/syslog

Useful keys::

Space → Next page
b → Previous page
q→ Quit

👉 Best for large log files.

Using tail

tail /var/log/syslog

Show last 10 lines.

Real-Time Monitoring (tail -f)

tail -f /var/log/syslog

👉 -f = follow live updates

This is one of the most-used debugging commands in production servers.

Stop with:

Ctrl + C

Searching Logs with grep

grep error /var/log/syslog

Case-insensitive:

grep -i failed /var/log/auth.log

Show latest matching errors:

grep error /var/log/syslog | tail -n 50

👉 Essential for filtering huge logs quickly.

Boot & Hardware Logs (dmesg)

dmesg

Shows:

Boot messages
Hardware detection
Kernel events

Useful for startup and hardware troubleshooting.

Modern Log System: journalctl

Modern Linux systems use systemd logs.

journalctl

Recent errors:

journalctl -xe

Specific service logs:

journalctl -u nginx

Live monitoring:

journalctl -f

Last 1 hour:

journalctl --since "1 hour ago"

👉 journalctl is the modern replacement for many traditional log files.

What is Log Rotation?

Logs grow continuously.

Without cleanup:

disks fill up
systems slow down

Linux automatically rotates logs using:

logrotate

👉 Old logs are compressed or removed automatically.

Real-Life Troubleshooting Example

Problem: Website is not working.

systemctl status nginx
tail -f /var/log/nginx/error.log
journalctl -u nginx -xe

👉 In real systems, logs usually reveal the exact root cause.

⚠️ Common Beginner Mistakes

guessing instead of checking logs
using cat on huge files
deleting logs blindly
ignoring tail -f
assuming service is healthy because it says “active”

Simple Mental Model

Think of logs like CCTV recordings:

system logs → building activity
auth logs → door access records
kernel logs → hardware monitoring
app logs → employee activity

👉 Debugging Linux = investigating evidence

Summary

what logs are
where logs are stored (/var/log)
important log files
cat, less, tail
live monitoring with tail -f
searching logs with grep
boot logs using dmesg
modern logging with journalctl
log rotation basics

Why Logs Matter

Logs are the foundation of:

Linux troubleshooting
DevOps debugging
production incident response
server monitoring
security analysis

👉 The better you read logs, the faster you solve problems.

End of Linux Beginner Series

You now learned:

Linux basics
filesystem structure
permissions
users & groups
processes
disk usage
networking
logs & troubleshooting

That’s already more Linux knowledge than most beginners have.

Final Next Step:
Linux Troubleshooting Flow for Beginners

Final Question

Which topic in this Linux series helped you the most?

And what Linux topic should the next series cover?

How CoreDNS Powers Service Discovery in Kubernetes

Sreekanth Kuruba — Tue, 23 Jun 2026 12:00:47 +0000

CoreDNS is the DNS server that powers service discovery in Kubernetes. This post explains how Pods translate Service names into IP addresses, explores common DNS records, and provides practical troubleshooting commands for debugging connectivity issues.

In the previous post, we learned how Kubernetes Services provide stable virtual IPs for Pods.

But another question remains:

How do applications find those Services?

Before kube-proxy can forward traffic to a Service, Kubernetes first needs to translate the Service name into its ClusterIP. That's exactly what CoreDNS does.

Applications rarely communicate using IP addresses. Instead, they use names such as:

backend-service
mysql-service
redis-service

So how does a Pod translate those names into IP addresses?

That's where CoreDNS comes in.

Why Do We Need DNS in Kubernetes?

Imagine a frontend application connecting to a backend Service.

Without DNS:

Backend IP = 10.96.15.21

If the Service IP changes, the application configuration must change.

With DNS:

backend-service

CoreDNS automatically resolves the name to the correct Service IP.

This allows applications to communicate without knowing actual IP addresses.

What Is CoreDNS?

CoreDNS is the DNS server for Kubernetes clusters.

It watches Kubernetes resources and automatically creates DNS records for:

Services
Pods (optional)
Namespaces

Applications can then use Service names instead of IP addresses.

Where Does CoreDNS Run?

CoreDNS runs as Pods inside the kube-system namespace.

Verify this with:

kubectl get pods -n kube-system

Typical output:

coredns-xxxxx
coredns-yyyyy

Multiple replicas provide high availability.

How Service Discovery Works

Suppose we have:

Service Name: backend-service
Namespace: default
ClusterIP: 10.96.15.21

A Pod sends a request to:

backend-service

CoreDNS resolves it to:

10.96.15.21

The application never needs to know the actual IP address.

Kubernetes DNS Naming

DNS Name	Used When
`backend-service`	Same namespace
`backend-service.default`	Specify the namespace
`backend-service.default.svc`	Include the Service domain
`backend-service.default.svc.cluster.local`	Fully Qualified Domain Name (FQDN)

Most applications simply use backend-service because Kubernetes automatically appends the remaining DNS suffix.

Why Does backend-service Work Without Typing the Full DNS Name?

Every Pod receives a DNS configuration file:

cat /etc/resolv.conf

It contains the CoreDNS nameserver and search domains, allowing short Service names like backend-service to resolve automatically without typing the full FQDN.

DNS Lookup Flow

Application Pod
        ↓
DNS Query
        ↓
CoreDNS
        ↓
Service ClusterIP
        ↓
kube-proxy
        ↓
Backend Pod

The entire process usually takes only a few milliseconds.

Important DNS Records

ClusterIP Service

CoreDNS returns the Service IP:

backend-service → 10.96.15.21

Headless Service

If the Service uses:

clusterIP: None

CoreDNS returns the individual Pod IPs:

database-0
database-1
database-2

This is commonly used by StatefulSets.

Common DNS Problems and Solutions

1. Service name not resolving?

Verify the Service exists:

kubectl get svc

2. Test DNS from a Pod

kubectl exec -it <pod> -- nslookup backend-service

3. Check CoreDNS Pods

kubectl get pods -n kube-system

4. View CoreDNS Logs

kubectl logs -n kube-system deployment/coredns

Why CoreDNS Matters

Without CoreDNS:

Applications would need hardcoded IP addresses.
Configuration changes would happen frequently.
Service discovery would become difficult.
Microservices communication would break easily.

CoreDNS makes Kubernetes applications independent of changing IP addresses.

Summary

Pods communicate using names, not IP addresses.

CoreDNS acts as the phonebook of Kubernetes, translating Service names into IP addresses.

Understanding CoreDNS helps you:

Debug Service discovery problems.
Troubleshoot application connectivity.
Understand Kubernetes networking better.
Build resilient microservices.

Next in the Series:
Ingress Explained – How External Traffic Enters Your Kubernetes Cluster.

Linux Networking Basics for Beginners

Sreekanth Kuruba — Tue, 23 Jun 2026 05:18:20 +0000

Post: 6

Most Linux “server down” problems are not actually system failures.

They are network issues.

👉 The system is running fine
👉 But it cannot talk to the outside world

That’s why networking is one of the most critical skills in Linux, DevOps, and cloud environments.

Let’s simplify it.

Basic Networking Concepts (Must Know First)

What is an IP Address?

An IP address is a unique address assigned to a device in a network.

Example:

192.168.1.10

👉 Used for communication between systems.

What is localhost (127.0.0.1)?

localhost refers to your own computer.

127.0.0.1

👉 This means “your own computer”

Used for:

testing apps
local development
debugging services

What is DNS?

DNS (Domain Name System) converts domain names into IP addresses.

Example:

google.com → 142.x.x.x

👉 Without DNS, we would need to remember IPs manually.

What is a Port?

Ports are like “doors” for services.

Ports are communication endpoints used by applications.

Examples:

Port 80 → HTTP
Port 443 → HTTPS
Port 22 → SSH

👉 One server can run multiple services using different ports.

1. Check Internet Connectivity with `ping`

ping google.com

Limit requests:

ping -c 4 google.com

👉 First command used in troubleshooting.

Checks:

is host reachable?
is network working?

2. Test Web Requests with `curl`

curl google.com

Headers only:

curl -I google.com   # Show only HTTP headers

Verbose mode:

curl -v google.com   # Verbose (detailed output)

Used for:

API testing
checking web services
debugging HTTP issues

3. Check DNS Resolution

nslookup google.com

# More detailed DNS lookup
dig google.com

👉 If DNS fails:

website won’t open
even if internet is working

4. Check Your IP Address

ip a          # full network interface details
hostname -I   # Show only IP addresses

👉 Shows your system’s network identity

5. Check Routing path

ip route
ip route | grep default   # Show default gateway

👉 Shows how traffic leaves your system

6. Check Open Ports

ss -tuln               # Show listening ports
ss -tuln | grep :80    # Check specific port

Shows which services are listening on your system.

Modern replacement for netstat.

7. Trace Network Path with `traceroute`

traceroute google.com

Install if needed:

sudo apt install traceroute    # Ubuntu/Debian
sudo dnf install traceroute    # Fedora/RHEL

👉 Shows where delay or failure happens in network path

8. Enhanced Traceroute with `mtr`

mtr is a powerful combination of ping and traceroute. It continuously monitors the connection.

mtr google.com

Install if needed:

sudo apt install mtr

👉 Combines:

ping
traceroute

Real-time network diagnostics tool

Simple Troubleshooting Flow (VERY IMPORTANT)

ping 8.8.8.8 → check internet
ping google.com → check DNS
ip a → check IP
ip route → check routing
curl -I site → check HTTP
traceroute / mtr → find failure point

👉 This is real DevOps incident workflow

⚠️ Common Beginner Mistakes

assuming internet is down (when DNS is broken)
not checking IP address first
using old tools (ifconfig, netstat)
routing checks

Simple Mental Model

Think of networking like delivery:

IP → house address
DNS → contact name → address lookup
Port → door number
Routing → delivery path
ping → “are you there?”

Summary

You learned:

IP address basics
localhost (127.0.0.1)
DNS resolution
ports (80, 443, 22)
ping → connectivity
curl → web/API testing
nslookup, dig → DNS tools
ip a, ip route → network config
ss → open ports
traceroute, mtr → path debugging

Why This Matters

Networking is the backbone of:

cloud systems
DevOps pipelines
APIs
production servers

👉 If networking breaks, everything breaks

Next Post:
Linux Logs Explained Simply,(journalctl, /var/log)

Question for You

Have you ever faced a situation where:

internet was working
but website still didn’t load?

That’s usually DNS — I’ll show debugging in Part 8.

Real production lesson: Logs can fill a server faster than applications. Always monitor /var/log growth before it becomes an outage. #sre #devops

Sreekanth Kuruba — Mon, 22 Jun 2026 11:33:25 +0000

Real production lesson: Logs can fill a server faster than applications. Always monitor /var/log growth before it becomes an outage. #sre #devops

Sreekanth Kuruba — Mon, 22 Jun 2026 11:33:02 +0000

SSH Sessions Dropping Frequently? Here's Exactly How I Troubleshoot It

Sreekanth Kuruba — Sat, 20 Jun 2026 07:56:43 +0000

Ever had your SSH session disconnect right in the middle of a production deployment?

I have.

After getting burned by it a few times, I created a simple troubleshooting checklist that helps me quickly find the root cause.

You're in the middle of a critical deployment or debugging session on a production server.

Suddenly:

Connection to 172.20.10.5 closed by remote host.

You reconnect… and it happens again 5 minutes later.

If this sounds familiar, you're not alone. SSH disconnections are one of the most frustrating issues for developers and DevOps engineers.

Here's the exact checklist I use to diagnose and fix recurring SSH disconnect problems.

1. Check Network Connectivity First

ping <server-ip>
traceroute <server-ip>
mtr <server-ip>          # Great for intermittent network issues

Look for:

Packet loss
High latency
Unstable VPN connections
ISP connectivity issues

Sometimes the problem isn't the server at all.

2. Check Server Resource Usage

Overloaded servers often become unresponsive and can drop SSH sessions.

top
htop
free -h
uptime

Pay special attention to:

High load average
Very low available memory
OOM (Out Of Memory) Killer activity
CPU saturation

3. Check SSH Logs

SSH logs often tell you exactly why the connection was terminated.

Ubuntu/Debian

sudo tail -f /var/log/auth.log

RHEL/CentOS/Rocky

sudo tail -f /var/log/secure

Modern systems

sudo journalctl -u sshd -f

Look for:

Timeout messages
Authentication failures
SSH daemon restarts
Connection errors

4. Fix SSH Timeout Settings (Server Side)

Edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Add or modify:

ClientAliveInterval 300
ClientAliveCountMax 3

This means:

Send a keepalive packet every 300 seconds.
Disconnect only after 3 failed responses.

Restart SSH:

sudo systemctl restart sshd

5. Configure Client-Side Keepalive

Create or edit:

nano ~/.ssh/config

Add:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

This helps prevent many idle SSH disconnections.

6. Check Firewalls, VPNs & Load Balancers

Some common culprits:

Firewall idle timeouts
Cloud load balancer timeouts
VPN session timeouts
NAT session expiration

Always troubleshoot the entire network path, not just the server.

7. Use `tmux` or `screen` (A Life Saver)

tmux
# Do your work
Ctrl + B then D   # Detach
tmux attach       # Reconnect later

This is a must-have habit for anyone working on Linux servers.

Even if your SSH session disconnects, your processes keep running.

8. Check System Limits

ulimit -a
cat /etc/security/limits.conf

Low limits can sometimes cause unexpected connection issues under heavy load.

Bonus Tip: Enable SSH Debugging

If the issue is difficult to reproduce:

ssh -vvv user@server-ip

The verbose output often reveals:

Authentication issues
Timeout problems
Network interruptions
Key exchange failures

A Real Production Incident

During a late-night deployment, our SSH sessions kept disconnecting every 3–4 minutes.

We initially suspected the server itself. CPU and memory looked fine, and SSH logs showed nothing unusual.

The actual culprit?

A firewall between our workstation and the server had an aggressive idle timeout configured.

Increasing the timeout and enabling SSH keepalives fixed the issue completely.

That incident taught me an important lesson:

Don't just troubleshoot the server. Troubleshoot the entire path between your machine and the server.

My SSH Troubleshooting Flow

SSH Keeps Disconnecting
        ↓
1. Network (ping/mtr)
        ↓
2. Server Resources (top/free)
        ↓
3. SSH Logs
        ↓
4. Timeout Settings (Server + Client)
        ↓
5. Firewall / LB / VPN
        ↓
6. Use tmux (always)

Final Thoughts

Most SSH disconnections usually come down to:

Idle timeout settings
Unstable network connections
Resource exhaustion
Firewall or VPN timeouts
Missing keepalive configuration

One final tip: I never perform deployments directly in a normal SSH session anymore.

Everything runs inside tmux.

Even if my connection drops, my work keeps running.

Have you ever faced a strange SSH disconnect issue? I'd love to hear your experience in the comments.

Linux Disk Usage Explained Simply

Sreekanth Kuruba — Wed, 17 Jun 2026 03:00:00 +0000

post: 5

One of the fastest ways to break a Linux system is this:

❌ Running out of disk space

When disk fills up:

apps crash
logs stop writing
deployments fail
servers become unstable

👉 That’s why disk usage monitoring is critical in Linux and DevOps.

Let’s simplify it.

Disk Usage Basics (You Must Know This First)

What is Storage in Linux?

Storage is where Linux keeps:

Files
Applications
Logs
Databases

Examples:

HDD
SSD
Cloud volumes (AWS, etc.)

If storage becomes full:

Applications may crash
Logs may stop writing
System can become unstable

Linux uses storage through filesystems.

What is a Filesystem?

A filesystem is how Linux organizes storage.

Examples:

ext4
xfs

Linux mounts filesystems into directories like:

/
/home
/var

File Size vs Disk Usage

File size → Size of a single file
Disk usage → Total space consumed by files and directories

Commands:

ls -lh → Check file size
du -sh → Check directory disk usage

What is Mounting?

Linux attaches storage devices to directories using a process called mounting.

Examples:

/ → Main filesystem
/home → User files
/var → Logs and application data

This is why df -h shows a Mounted on column.

1. Check Overall Disk Usage with `df`

df -h

Example Output:

Filesystem      Size  Used  Avail  Use%  Mounted on
/dev/sda1        50G   32G   18G   65%   /

Meaning:

Size → Total disk
Used → used space
Avail → Free space
Use% → usage percentage
Mounted on → where disk is attached

👉 First command to run when server behaves weirdly.

2. Check Folder and Directory Size with `du`

du -sh /home
du -sh /var/log

-s → Summary (total size only)
-h → Human readable (KB, MB, GB)

👉 Used to find which folder is consuming space

3. Find Large Files in the System

find / -type f -size +100M 2>/dev/null
find / -type f -size +500M 2>/dev/null

⚠️ Can take time on large systems.

👉 Common use:

large logs
backups
unused media files

4. Find Biggest Directories (Very Important)

du -sh /* 2>/dev/null | sort -hr | head -n 10

👉 Shows top 10 largest directories

This is one of the most used DevOps troubleshooting commands.

5. Disk Full but Space Looks Free? (INODES)

df -i

What are inodes?

Inodes store metadata about files.

👉 Problem:

Disk shows free space
But system says:

No space left on device

👉 Cause:
Too many small files.

This is very common in:

log systems
microservices
temp file-heavy apps

6. Deleted Files Still Using Space

lsof | grep deleted

👉 Happens when:

file is deleted
but process is still using it

So disk space is NOT freed.

Bonus Tool: `ncdu` (Best for Beginners)

sudo apt install ncdu   # Ubuntu/Debian
sudo dnf install ncdu   # Fedora/RHEL

Run:

ncdu /

Why it’s powerful:

interactive UI
easy navigation
visual disk breakdown

👉 Widely used by DevOps engineers for fast debugging

Basic Cleanup Tips

Remove old logs carefully
delete unused backups
Clear package cache when needed
Always verify before using rm -rf

⚠️ Common Beginner mistakes

Disk shows free space but system says full → Check inodes (df -i)
using rm -rf without checking size
ignoring /var/log growth

Simple Mental Model

Think of disk like a room:

/home → personal items
/var → messy logs piling up
/usr → installed apps
/tmp → temporary trash

👉 When room is full → system slows down

Summary

In this guide you learned:

df -h → Overall disk usage
du -sh → Folder size
find → Locate large files
df -i → Check inodes
lsof | grep deleted → Find deleted open files
ncdu → Interactive disk usage analyzer

Why This Matters

Disk issues are one of the most common production failures in:

DevOps systems
cloud servers
databases
CI/CD pipelines

👉 Knowing this = real-world Linux skill

Next Post:
Linux Networking Basics for Beginners,(ping, curl, ip, ss, etc.)

Question for You

Have you ever faced a server where disk was full but you couldn’t find why?

That’s usually inode or deleted file issues — I’ll show debugging tricks in Part 7.

DEV Community: Sreekanth Kuruba

Linux Troubleshooting Workflow for Beginners: A Step-by-Step Guide

File Compression in Linux Explained Simply (tar, gzip, zip & unzip)

Viewing Files in Linux Explained Simply (cat, less, head, tail & wc)

Finding Files & Text in Linux Explained Simply (find, grep, which & whereis)

Finding Files vs Searching Text

1. Find Files with find

2. Search Text Inside Files with grep

3. Find Executable Location with which

4. Find Program Files with whereis

Bonus: Fast File Search with locate

Real-World Troubleshooting Example

Common Beginner Mistakes

Simple Mental Model

Summary

Linux Package Management Explained Simply (apt, dnf, yum & rpm)

What is a Package?

What is a Package Manager?

Why Use a Package Manager?

What is a Repository?

Common Package Managers

Most Useful Commands

Low-Level Tool: rpm

Common Beginner Mistakes

Simple Mental Model

Summary

Why This Matters

Linux Logs Explained Simply

What Are Logs?

Where are Logs Stored?

Important Log Files

Real-Life Troubleshooting Example

⚠️ Common Beginner Mistakes

Summary

How CoreDNS Powers Service Discovery in Kubernetes

Important DNS Records

Common DNS Problems and Solutions

Linux Networking Basics for Beginners

Basic Networking Concepts (Must Know First)

1. Check Internet Connectivity with ping

2. Test Web Requests with curl

3. Check DNS Resolution

4. Check Your IP Address

5. Check Routing path

6. Check Open Ports

7. Trace Network Path with traceroute

8. Enhanced Traceroute with mtr

Simple Troubleshooting Flow (VERY IMPORTANT)

⚠️ Common Beginner Mistakes

Summary

Real production lesson: Logs can fill a server faster than applications. Always monitor /var/log growth before it becomes an outage. #sre #devops

Real production lesson: Logs can fill a server faster than applications. Always monitor /var/log growth before it becomes an outage. #sre #devops

SSH Sessions Dropping Frequently? Here's Exactly How I Troubleshoot It

1. Check Network Connectivity First

2. Check Server Resource Usage

3. Check SSH Logs

Ubuntu/Debian

RHEL/CentOS/Rocky

Modern systems

4. Fix SSH Timeout Settings (Server Side)

5. Configure Client-Side Keepalive

6. Check Firewalls, VPNs & Load Balancers

7. Use tmux or screen (A Life Saver)

8. Check System Limits

Bonus Tip: Enable SSH Debugging

A Real Production Incident

My SSH Troubleshooting Flow

Final Thoughts

Linux Disk Usage Explained Simply

Disk Usage Basics (You Must Know This First)

What is a Filesystem?

File Size vs Disk Usage

What is Mounting?

1. Check Overall Disk Usage with df

2. Check Folder and Directory Size with du

3. Find Large Files in the System

4. Find Biggest Directories (Very Important)

5. Disk Full but Space Looks Free? (INODES)

6. Deleted Files Still Using Space

Bonus Tool: ncdu (Best for Beginners)

1. Find Files with `find`

2. Search Text Inside Files with `grep`

3. Find Executable Location with `which`

4. Find Program Files with `whereis`

Bonus: Fast File Search with `locate`

1. Check Internet Connectivity with `ping`

2. Test Web Requests with `curl`

7. Trace Network Path with `traceroute`

8. Enhanced Traceroute with `mtr`

7. Use `tmux` or `screen` (A Life Saver)

1. Check Overall Disk Usage with `df`

2. Check Folder and Directory Size with `du`

Bonus Tool: `ncdu` (Best for Beginners)