Linux File System Hierarchy & Scenario-Based Practice

Goal: Know where things live on Linux and practice troubleshooting flows like a DevOps engineer.

Part 1 — File System Hierarchy (core directories)

For each directory below: run ls -l <directory> and note 1–2 items you see. Add one short sentence: “I would use this when…”.

/ (root)

• What: The filesystem root — all files and directories stem from here.
• Typical entries: bin, etc, usr, var, home (run ls -l / to confirm).
• I would use this when: I need to check mount points, boot files, or overall layout of the system.

/home

• What: Users’ home directories (e.g., /home/malik).
• Typical entries: users’ folders, dotfiles in each home (run ls -la /home).
• I would use this when: I need user configs, scripts, or per-user logs.

/root

• What: The root user’s home directory.
• Typical entries: admin dotfiles and root-owned scripts.
• I would use this when: performing privileged maintenance as root.

/etc

• What: System and application configuration files.
• Typical entries: passwd, hosts, ssh/ (run ls -l /etc | head).
• I would use this when: editing service configuration or checking system settings.

/var/log

• What: Persistent log files (service logs, system logs).
• Typical entries: syslog, auth.log, docker/ (run ls -l /var/log).
• I would use this when: investigating incidents and service failures.

/tmp

• What: Temporary files; cleared on reboot on many systems.
• Typical entries: temporary sockets and temp files for running processes.
• I would use this when: verifying ephemeral files or recreating temp artifacts.

Additional directories (good to know)

• /bin — Essential user binaries (e.g., ls, bash).
• /usr/bin — Additional user binaries (larger collection).
• /opt — Optional third-party applications and packages.

Hands-on sanity checks:

# Find largest log files
du -sh /var/log/* 2>/dev/null | sort -h | tail -5

# Look at a config
cat /etc/hostname

# Check your home
ls -la ~

Part 2 — Scenario-Based Practice (step-by-step)

Tip: Focus on investigation flow: check status → inspect logs → collect evidence → act.

Solved example — Check if nginx is running

1. systemctl status nginx Why: Shows active/failed state and recent log snippets.
2. systemctl list-units --type=service | grep nginx Why: Confirms the unit name and whether it exists.
3. systemctl is-enabled nginx Why: Tells if it will start on boot.
4. journalctl -u nginx -n 50 --no-pager Why: Read recent service logs for errors.

Scenario 1 — Service Not Starting (myapp)

Step 1: systemctl status myapp Why: See immediate state and hints (failed, inactive, not-found).

Step 2: journalctl -u myapp -n 100 --no-pager Why: Inspect logs for startup errors or dependency failures.

Step 3: systemctl is-enabled myapp Why: Confirm whether it should start on boot.

Step 4: systemctl list-dependencies myapp Why: Check if a dependent unit is failing.

Scenario 2 — High CPU Usage (identify culprit)

Step 1: top (or htop) Why: Live view of CPU and memory — spot top consumers.

Step 2: ps aux --sort=-%cpu | head -n 10 Why: Get a snapshot of highest CPU processes and PIDs.

Step 3: pidstat -p <PID> 1 5 Why: Observe per-thread CPU usage over time (optional but useful).

Step 4: strace -p <PID> -c (capture short trace) Why: If suspicious activity, trace system calls to find hotspot.

Scenario 3 — Finding Service Logs (docker)

Step 1: systemctl status docker Why: Quick status and unit info.

Step 2: journalctl -u docker -n 50 --no-pager Why: Read recent docker service logs.

Step 3: journalctl -u docker -f Why: Follow logs in real time while reproducing the issue.

Step 4: ls -l /var/log/ | grep docker Why: Check if any docker-related files exist on disk for persistent logs.

Scenario 4 — File Permissions Issue (/home/user/backup.sh)

Step 1: ls -l /home/user/backup.sh Why: See current permissions and ownership.

Step 2: chmod +x /home/user/backup.sh Why: Add execute bit so script can run.

Step 3: ls -l /home/user/backup.sh Why: Verify the x bit is present.

Step 4: ./backup.sh Why: Run the script and confirm it executes.

Quick Notes & Why This Matters

• Know where logs and configs live (/var/log, /etc) so you can reach evidence fast.
• Practice structured flows: status → logs → resource checks → action.
• These scenarios prepare you for real incidents and common interview questions.