DEV Community: Sreekanth Kuruba

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.

How Does Traffic Actually Reach Your Pods? Kubernetes Services & kube-proxy Explained

Sreekanth Kuruba — Tue, 16 Jun 2026 08:29:38 +0000

Your backend Pod just crashed.

Kubernetes created a new Pod with a completely different IP address.

Yet your application didn't notice anything changed.

How?

Because applications don't talk directly to Pods.

They talk to Kubernetes Services.

A Service provides a stable virtual IP and DNS name, while kube-proxy quietly programs the networking rules that route traffic to the right Pods.

In this post, we'll go beyond the usual "Service types" explanation and look at how traffic actually reaches your Pods under the hood.

What is a Kubernetes Service?

A Service provides a stable virtual IP (ClusterIP) and DNS name for a dynamic set of Pods.

Think of it as a permanent front door for Pods that may come and go.

Key points:

Services provide a stable endpoint for applications.
Pods behind a Service can change without affecting clients.
Services use labels and selectors to automatically discover matching Pods.
The Service IP is virtual—there is no process directly listening on that IP.

Important:

A ClusterIP doesn't belong to a real network interface, and no process is directly listening on that IP.

Instead, kube-proxy programs networking rules on every node so packets sent to the ClusterIP are transparently redirected to backend Pods.

How Does a Service Find Its Pods?

Kubernetes uses labels and selectors to determine which Pods belong to a Service.

Example:

Service selector:
app=backend

Matching Pods:
app=backend

Non-matching Pods:
app=frontend

Only the matching Pods become Service endpoints and receive traffic from the Service.

Why Do We Need Services?

Imagine a Deployment with three Pods:

backend-1 → 10.244.1.5
backend-2 → 10.244.2.8
backend-3 → 10.244.3.12

If backend-2 crashes, Kubernetes creates:

backend-4 → 10.244.2.15

The old IP disappears.

Without Services, every client would need to know the new Pod IPs constantly.

Services solve this problem by giving applications a stable endpoint.

Types of Kubernetes Services

1. ClusterIP (Default)

Accessible only inside the cluster.
Used for communication between microservices.

2. NodePort

Exposes the application on a port of every Kubernetes node.
Useful for testing and simple external access.

3. LoadBalancer

Creates an external load balancer using your cloud provider.
Commonly used for production applications.

4. ExternalName

Maps a Service to an external DNS name using a CNAME record.
Useful for integrating external services.

How Services Work Under the Hood

When you create a Service:

Kubernetes allocates a ClusterIP.
Kubernetes creates EndpointSlices, which contain the healthy Pod IPs behind the Service.
kube-proxy running on every node watches for Service and EndpointSlice changes.
kube-proxy programs networking rules on the node.
Traffic sent to the Service IP is automatically redirected to one of the backend Pods.

kube-proxy: The Unsung Hero

Many people think kube-proxy forwards packets itself.

It doesn't.

Its job is to configure the node's networking rules so Linux can route traffic efficiently.

kube-proxy can run in three modes:

iptables Mode

Most common deployment mode.
Uses iptables rules for load balancing and NAT.

IPVS Mode

Uses Linux IP Virtual Server.
Better scalability and performance for large clusters.

Userspace Mode

Legacy mode.
Rarely used today.

Traffic Flow Example

Client Pod
      ↓
Service (ClusterIP)
      ↓
kube-proxy Rules
      ↓
┌─────┬─────┬─────┐
Pod A Pod B Pod C

When a request is sent to a Service:

The packet reaches a node.
kube-proxy's rules match the Service IP and port.
Destination NAT (DNAT) redirects the request to one of the healthy Pods.
The Pod sends the response back to the client.

All of this happens transparently.

The client thinks it is communicating with a single stable IP.

Common Service Problems

Pods are not receiving traffic?

Check whether labels match the Service selector.

kubectl describe service <service-name>
kubectl get endpointslices

No backend Pods found?

Verify the Pods are Ready.

kubectl get pods -o wide

Debug kube-proxy Rules

ipvsadm -Ln
iptables -t nat -L KUBE-SERVICES -n

Fun Fact

Some modern networking solutions like Cilium can replace kube-proxy entirely using eBPF, reducing iptables complexity and improving observability.

Summary

Pods are temporary, and their IP addresses can change at any time.

Kubernetes Services provide a stable entry point, while kube-proxy makes the magic happen by programming networking rules on every node.

Understanding this flow helps you:

Debug Service connectivity issues faster
Choose the right Service type
Understand how traffic moves inside Kubernetes
Build more reliable Kubernetes applications

Next in the Series: CoreDNS Explained – How Kubernetes Turns Service Names into IP Addresses

Linux Process Management Explained Simply

Sreekanth Kuruba — Tue, 09 Jun 2026 03:02:49 +0000

post: 4

Ever opened a Linux server and thought:

“Why is everything so slow or frozen?”

Most of the time, the problem is not Linux itself.

It’s running processes consuming resources in the background.

Let’s understand it simply.

What is a Process?

A process is a running program or service on your Linux system.

Examples:

Web browser
Web server (Nginx/Apache)
Database (MySQL, PostgreSQL)
Background services

What is PID?

Every process has a unique ID called a PID (Process ID).

PID = identity number of a running program

Example:

Chrome → PID 1234
Nginx → PID 5678

👉 You use PID to control processes (stop, monitor, debug).

1. Viewing Processes with `ps`

ps

Shows processes in current terminal only.

Better command:

ps aux

Shows ALL processes with:

CPU usage
Memory usage
User
PID
Command

👉 This is a daily DevOps debugging command.

Full system view:

ps -ef

Shows process hierarchy (parent → child relationships)

Difference:

Command         Use

ps aux          Resource monitoring (CPU/MEM)
ps -ef          Process structure view

2. Real-Time Monitoring `top`

top

top Shows live system activity:

You can see:

CPU usage
Memory usage
Running processes

Useful keys inside top:

q → Quit
k → Kill a process
M → Sort by memory usage
P → Sort by CPU usage

👉 Used when servers suddenly slow down or spike.

3. Better version: `htop`

# Install if not available:
sudo apt install htop     # Ubuntu/Debian
sudo dnf install htop     # Fedora/RHEL

Why devs prefer htop:

Colorful UI
Easier navigation
Process tree view
Simple killing of processes

👉 Much more user-friendly than top

4. Finding Specific Processes

ps aux | grep nginx
ps aux | grep python

Better alternatives:

pgrep nginx          # Returns only PIDs
pidof nginx          # Another way to get PID

👉 Faster way to get PID directly

5. Killing Processes

kill 1234            # Graceful kill
kill -9 1234         # Force kill (use only when necessary)

-> You must know the PID of the process to use kill.

Safer & easier ways:

pkill nginx          # Kill by process name
killall firefox      # Kill all processes with that name

⚠️ Always double-check PID before killing a process.

Wrong kill = system instability.

6. Background & Foreground Jobs

Foreground Process:

Runs in terminal and blocks it.

Background Process:

Runs without blocking terminal

Example:

sleep 100 &

& → sends process to background
You can continue using terminal

Useful commands:

jobs → Show background jobs
fg → Bring job to foreground
bg → Resume paused job in background

Useful when multitasking in terminal sessions.

7. Find Heavy Processes (CPU / Memory)

# Sort by CPU (highest first)
ps aux --sort=-%cpu | head

# Sort by Memory (highest first)
ps aux --sort=-%mem | head

👉 Very useful in production debugging.

⚠️ Important Safety Warning

Never kill critical system processes such as:

systemd
init
kernel processes (usually shown with square brackets)

👉 Doing so can crash your system completely.

Simple Mental Model

Think of Linux like a city:

Each app = a citizen
PID = ID card
CPU = energy usage
RAM = working space

Process management = controlling city traffic 🚦

Summary

In this guide you learned:

What a process is
What PID means
How programs run in Linux
Viewing processes (ps, top, htop)
Finding processes (grep, pgrep, pidof)
Killing processes safely (kill, pkill, killall)
Foreground vs background processes
Monitoring CPU and memory usage

why This Matters

Process management is used in:

DevOps debugging
Server monitoring
Performance optimization
Cloud environments
Production troubleshooting

👉 This is a core real-world Linux skill.

Next Post:
Linux Disk Usage Explained Simply, (df, du, mounting basics)

Question for You

Have you ever faced a server slowdown because of a single process?

I’ll show how to identify it instantly in Part 6.

Linux User & Group Management Explained Simply

Sreekanth Kuruba — Thu, 28 May 2026 12:42:16 +0000

post: 3

Ever wondered how Linux knows:

who can access what, and what they are allowed to do?

That’s not random.

It’s controlled by users and groups — one of the most important concepts in Linux security and DevOps.

Let’s break it down simply.

What is a User in Linux?

A user is an account that interacts with the Linux system.

Every user has:

Username
User ID (UID)
Home directory
Default shell

Everything in Linux runs under a user identity.

Examples:

A developer user
A system admin user
A service user (like nginx)

What is a Group in Linux?

A group is a collection of users.

Think of it like a team:

Developers group → devs
QA group → testers
Admins group → system administrators

👉 Instead of assigning permissions one by one, you assign them to a group.

This makes Linux scalable and manageable.

Check Current User & Groups

whoami

Shows your current logged-in user.

id

Shows:

User ID (UID)
Group ID (GID)
All groups the user belongs to

groups

Shows all groups of the current user.

Creating a User

sudo useradd john

Creates a new user named john.

Note: This may not create a home directory in some systems.

Better way (recommended on Ubuntu/Debian):

sudo adduser john

👉 Automatically creates home directory + setup

Setting Password

sudo passwd john

Used to set or update user password.

Modifying Users (`usermod`)

sudo usermod -aG developers john

Adds user john to developers group.

Other examples:

sudo usermod -l newname oldname   # rename user
sudo usermod -d /new/home john    # change home directory

Deleting Users

sudo userdel john

Removes user only.

Remove user + home directory:

sudo userdel -r john

Managing Groups

Creating a Group

sudo groupadd developers

Deleting a Group

sudo groupdel developers

Important System Files

`/etc/passwd`

Stores user information:

username:x:UID:GID:comment:home:shell

Example:

john:x:1001:1001::/home/john:/bin/bash

👉 This file contains all users in the system.

`/etc/group`

Stores group information:

group_name:x:GID:user_list

Example:

developers:x:1002:john,mike

👉 Shows which users belong to which group.

What is sudo?

sudo allows a user to run commands as an administrator (root).

Example:

sudo apt update

Why sudo is important

Linux protects system files.

Normal users cannot modify system-level settings.

👉 sudo gives temporary admin power.

Important sudo concept

Not every user has sudo access
Only users in sudo or wheel group can use it

Check your groups:

groups

Real-World Example

In a company server:

Developers → normal users
Admins → sudo users
Services → system users (nginx, docker, etc.)

Each user has restricted access based on role

This keeps systems:

security
structure
control ⚙️

Why User & Group Management Matters

In DevOps and system administration:

You use this to:

control server access
manage teams on shared systems
secure applications
isolate services

Without it:

Linux systems become unmanageable and insecure

Summary

In this guide you learned:

What users are in Linux
What groups are
whoami, id, groups
useradd, adduser
usermod usage
userdel and cleanup
groupadd, groupdel
/etc/passwd structure
/etc/group structure
sudo basics
Real-world DevOps usage

Linux Process Management Explained Simply, (ps, top, htop, kill)

Question for You

Have you ever worked on a shared Linux server where multiple users caused confusion or permission issues?

I’ll show how real systems solve that in Part 5.

DEV Community: Sreekanth Kuruba

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)

⚠️ Common Beginner mistakes

Summary

How Does Traffic Actually Reach Your Pods? Kubernetes Services & kube-proxy Explained

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)

1. Viewing Processes with `ps`

2. Real-Time Monitoring `top`

3. Better version: `htop`

Modifying Users (`usermod`)

`/etc/passwd`

`/etc/group`