🐧 Linux Debugging — 15 Real-World DevOps Interview Q&A
✅ Q1 — Server CPU is 100%. How do you debug?
First I run top or htop to identify the process consuming CPU. Then ps -eo pid,cmd,%cpu --sort=-%cpu | head. If needed, I check per-thread usage with top -H. Then I analyze whether it’s expected load, loop bug, or runaway job.
✅ Q2 — Memory usage is high — how do you find root cause?
Use free -m to see used vs available. Then top sorted by memory. Check ps aux --sort=-%mem. I also check cache vs real usage — Linux uses memory for cache aggressively. Swap usage is key signal.
✅ Q3 — System is slow but CPU is low — what next?
Check IO wait using top (%wa) and iostat -x. High IO wait means disk bottleneck. Then check disk busy processes using iotop. Slow systems are often IO-bound, not CPU-bound.
✅ Q4 — Disk full — but du shows less usage — why?
Likely deleted files still held by running processes. Check with lsof | grep deleted. Restarting that process releases space. Common with log files.
✅ Q5 — Which process is using a port?
Use ss -tulpn or netstat -tulpn. Shows PID and program bound to port. Useful for port conflicts or security checks.
✅ Q6 — App cannot connect to remote host — debug steps?
Test DNS with dig or nslookup. Test network with ping and traceroute. Test port with nc -zv host port or telnet. This separates DNS vs routing vs firewall issue.
✅ Q7 — High load average — what does it actually mean?
Load average = runnable + waiting processes. Not just CPU usage. High load with low CPU often means IO wait or lock contention. I correlate with CPU and IO stats.
✅ Q8 — Process keeps crashing — how investigate?
Check logs first. Then journalctl -u service if systemd. Check exit code and core dumps. Run process manually in foreground if possible. Look for OOM kills in dmesg.
✅ Q9 — How do you detect OOM killer events?
Run dmesg | grep -i oom. Kernel logs show killed process. Also visible in syslog/journal. Indicates memory limit breach.
✅ Q10 — File descriptor limit reached — symptoms & fix?
App errors like “too many open files”. Check with lsof | wc -l and ulimit -n. Increase limits in /etc/security/limits.conf and systemd config. Restart service.
✅ Q11 — Zombie processes — what are they and fix?
Zombie = finished process not reaped by parent. Seen as “Z” in ps output. Fix parent process or restart it. Zombies themselves use little resource but indicate bug.
✅ Q12 — Service not starting — systemd debug steps?
Use systemctl status service. Then journalctl -xe. Check ExecStart path and permissions. Run command manually. Most failures are path or env issues.
✅ Q13 — Network connections leaking — how detect?
Use ss -s for summary. lsof -i for per-process sockets. Check TIME_WAIT flood. Often caused by connection pool misconfig.
✅ Q14 — Cron job not running — debug?
Check crontab entry and user crontab. Check /var/log/cron or journal. Verify PATH inside cron — it’s minimal. Use full paths in cron commands.
✅ Q15 — How do you quickly inspect what changed recently on system?
Check last, lastlog, bash history, file mtimes with ls -lt. Check config dirs diff vs backup. Check package updates with package manager logs.