“Where are logs stored?”
“Where do configuration files live?”
“How do I start troubleshooting?”

Good news: Linux is not random.
It has a clear structure, like a well-organized city 🏙️

• Some places store user files

• Some store system settings

• Some store logs

• Some store programs

Today you’ll learn:
✔ Where important things live in Linux
✔ How DevOps engineers find logs and configs
✔ How to solve real-world issues step by step

This is real DevOps thinking.

📁 PART 1 — Linux File System Hierarchy (Must Know)

/ — Root Directory (The Starting Point)

This is the top of the Linux file system. Everything starts here.

ls -l /

Think of / like the main entrance of a building.

👉 I would use this when exploring the overall system layout.

/home — User Home Directories

Each normal user gets a folder here.

ls -l /home

Example:

student/
john/
devops/

This is where users keep their files, scripts, and projects.

👉 I would use this when working with user data.

/root — Root User’s Home

This is the home directory of the administrator (root).

ls -l /root

This is like the admin office — normal users don’t have access.

👉 I would use this when doing system-level admin tasks.

/etc — Configuration Files (System Control Room)

Almost all system and service settings live here.

ls -l /etc | head
cat /etc/hostname

Examples:

• /etc/ssh/sshd_config → SSH settings

• /etc/nginx/nginx.conf → Web server settings

👉 I would use this when changing service configurations.

/var/log — Log Files (DevOps Gold Mine)

This is where system and application logs are stored.

ls -l /var/log | head
du -sh /var/log/* 2>/dev/null | sort -h | tail -5

Logs tell you what went wrong and when.

👉 I would use this when troubleshooting service failures.

/tmp — Temporary Files

Temporary files are stored here and often deleted after reboot.

ls -l /tmp

👉 I would use this for testing or short-term work.

/bin — Essential Commands

Core Linux commands like ls, cp, mv live here.

ls -l /bin | head

/usr/bin — Installed Programs

Most user-installed programs are here.

ls -l /usr/bin | head

/opt — Optional / Third-Party Software

Custom or third-party software is often installed here.

ls -l /opt

🧠 PART 2 — Scenario-Based Troubleshooting

Now we act like DevOps engineers solving real problems.

🔧 Scenario 1 — Service Not Starting

Problem: A service named myapp did not start after reboot.

Step 1 — Check Service Status

systemctl status myapp

Shows if the service is running, stopped, or failed.

Step 2 — Check Service Logs

journalctl -u myapp -n 50

Shows last 50 log entries explaining why it failed.

Step 3 — Check If It Starts on Boot

systemctl is-enabled myapp

Checks if the service is configured to start automatically.

Step 4 — Confirm Service Exists

systemctl list-units --type=service | grep myapp

🔥 Scenario 2 — High CPU Usage

Problem: Server feels slow.

Step 1 — View Live CPU Usage

top

Shows real-time CPU usage and running processes.

Step 2 — Find Highest CPU Process

ps aux --sort=-%cpu | head -10

Lists top CPU-consuming processes.

Step 3 — Stop Problem Process

kill <PID>

Stops the heavy process (carefully).

📜 Scenario 3 — Finding Service Logs (Detailed)

Problem: A developer asks: “Where are the logs for Docker?”

Docker is managed by systemd, so logs are in the system journal.

Step 1 — Check Service Status

systemctl status docker

Confirms Docker is running and shows recent logs.

Step 2 — View Last 50 Log Entries

journalctl -u docker -n 50

Shows recent Docker errors or warnings.

Step 3 — Follow Logs Live

journalctl -u docker -f

Shows logs in real time while Docker runs.

🔒 Scenario 4 — File Permission Issue (Detailed)

Problem: Script gives “Permission denied”.

File:

/home/user/backup.sh

Step 1 — Check Permissions

ls -l /home/user/backup.sh

If you see:

-rw-r--r--

There’s no x (execute permission).

Step 2 — Add Execute Permission

chmod +x /home/user/backup.sh

Step 3 — Verify

ls -l /home/user/backup.sh

Now you should see:

-rwxr-xr-x

Step 4 — Run Script

./backup.sh

✅ Why This Matters for DevOps

You now understand:

✔ Where logs live
✔ Where configs live
✔ Where binaries live
✔ How to approach service, CPU, log, and permission issues