Linux for DevOps – What You Actually Use at Work

Introduction

Linux is the real runtime of DevOps.

Containers, Kubernetes, CI/CD, cloud — all of it eventually runs on Linux.

And in production, Linux is not about theory, certifications, or distro wars.

It's about answering questions like:

• Why is my service down?
• What is eating memory or CPU?
• Where are the logs?
• Why can't this process access a file?
• Why didn't the service start after reboot?

This blog covers only what you actually use at work:

• File system navigation
• Permissions (the real ones)
• Processes
• Logs
• systemd
• Practical commands only — no fluff

This is Linux explained like a production engineer.

Linux File System (What You Actually Touch)

You don't need to memorize the entire Linux file hierarchy.

In real DevOps work, you repeatedly use a small set of directories.

Important Directories

• / → Root of everything
• /etc → Configuration files
• /var/log → Application & system logs
• /opt → Custom applications
• /usr/bin → Installed binaries
• /home → User home directories
• /tmp → Temporary files
• /proc → Process & kernel info (virtual)

If you don't know /etc and /var/log, you will struggle in production.

---

Practical File System Commands

pwd                 # where am I
ls -lah             # list files with permissions & sizes
cd /path            # move around
du -sh *            # check folder sizes
df -h               # disk usage
stat file.txt       # detailed file info
find . -name "*.log"

Production tip:

Disk full issues are extremely common.

df -h and du -sh save lives.

Linux Permissions (Why Things Break)

Most production issues are permission issues, not bugs.

Linux permissions answer:

Who can read, write, or execute this file?

Permission Model

-rwxr-x---
 owner group others

• r → read
• w → write
• x → execute

Practical Permission Commands

ls -l
chmod 755 script.sh
chmod +x script.sh
chown user:group file
whoami
id

Common real-world problems:

• App can't read config in /etc
• Docker volume permission mismatch
• CI job fails due to file ownership

Production rule:

If it works as root but not as app user — it's a permission bug.

Processes (What Is Running & Why)

When something is slow or down, you inspect processes.

Practical Process Commands

ps aux
top
htop
uptime
free -h
vmstat

Kill & Inspect

kill PID
kill -9 PID
pkill process_name

Golden rule:

Never kill -9 first.

Try graceful shutdown before force.

Logs (Where the Truth Lives)

Logs are the source of truth in production.

If you don't check logs, you are guessing.

Common Log Locations

• /var/log/syslog
• /var/log/messages
• /var/log/nginx/
• /var/log/app-name/

Practical Log Commands

cat file.log
less file.log
tail -f file.log
grep "ERROR" file.log
grep -i "timeout" *.log

Production tip:

• tail -f during incidents
• grep during debugging

systemd (How Services Actually Run)

Modern Linux servers use systemd.

If your app runs in production, it probably runs as a systemd service.

Service Management Commands

systemctl status app.service
systemctl start app.service
systemctl stop app.service
systemctl restart app.service
systemctl enable app.service

Check Logs via systemd

journalctl -u app.service
journalctl -u app.service -f
journalctl --since "10 minutes ago"

Production truth:

If your service didn't start after reboot — check systemctl status.

Real-World Linux Debug Flow (Mental Model)

When something breaks in production, experienced DevOps engineers do this:

1. Is the server alive?

uptime

2. Is the process running?

ps aux | grep app

3. Is the service healthy?

systemctl status app

4. Check logs

journalctl -u app -n 100

5. Check disk & memory

df -h
free -h

This flow solves 80% of production incidents.

What You Don't Need (Initially)

You don't need:

• Kernel compilation
• Custom distros
• Deep bash wizardry
• Linux certification trivia

You need:

• Confidence on a terminal
• Ability to debug under pressure
• Understanding how Linux behaves in production

Conclusion

Linux for DevOps is not academic.

It's about:

• Finding problems fast
• Fixing issues safely
• Understanding what the system is telling you

If you master:

• File system
• Permissions
• Processes
• Logs
• systemd

You are already production-ready.

Everything else is optimization.

Production always wins. 🐧🚀