Core Code
Core Code Modern Dev Handbook
LINUX-PRODUCTION Contents
Linux Fundamentals for Production
Filesystem Layout (FHS) in Practice Users, Groups, and Service Accounts Permissions & ACLs (chmod/chown/setuid) Sudoers Safe Defaults Packages: apt/dnf, Repos, and Pinning Shell & Environment Hygiene Editing Configs Safely Time, Timezones, and NTP System Introspection Toolkit
Processes & Signals
Linux Process Model (PID, PPID, Fork/Exec) ps/top/htop: Finding What Hurts Signals in Practice (TERM/KILL/HUP) nice/renice and Scheduling Basics ulimits and Resource Limits Background Jobs (nohup, tmux, systemd-run) /proc and What It Tells You cgroups Basics (CPU/Memory Isolation) Zombies, Orphans, and Stuck Processes
systemd & Services
systemd Unit Types Overview Service Unit Best Practices Dependencies & Ordering (After/Wants/Requires) Restart Policies and Backoff Environment Files and Secrets Handling journald Basics (Reading, Filtering, Retention) Logging Practices with systemd Timers vs Cron Debugging systemd Services
Networking Basics for Production
ip, routes, and interfaces DNS Debugging (dig, resolvectl, hosts) Ports and Sockets with ss curl for HTTP Debugging TCP Basics (Handshake, States, Retries) Firewall Overview (nftables/iptables/ufw) NAT and Port Forwarding Concepts TLS and Certificates Basics Network Troubleshooting Playbook
Storage & Filesystems
Disk Layout and Partitioning (lsblk/fdisk) Filesystems (ext4/xfs) Basics Mounts and /etc/fstab Safety Disk Usage: df vs du (and Why They Differ) Inodes and “Disk Full” Mysteries Swap Strategy in Production Log Rotation (logrotate) Basics Temporary and Runtime Storage Hygiene Backup Storage Considerations
Security Basics
SSH Hardening in Production Users and Least Privilege in Production Firewall Minimum Rules for Production Linux Patching Strategy in Production Managing Secrets on Linux Hosts Linux Audit and Basic Logging in Production Fail2ban and Rate Limiting in Production SELinux and AppArmor Overview in Production Linux Security Baseline Checklist for Production
Observability on Linux
Linux Log Sources Map in Production journalctl Power Usage in Production Log Structure and Correlation in Production Metrics Hooks Overview in Production Health Checks and Readiness in Production Tracing Mindset for Linux and Production Systems Core Dumps Basics in Production Debug Packages and Symbols in Production Linux Observability Checklist for Production
Performance & Debugging
Load Average Explained for Production Debugging CPU Profiling Basics in Linux Production Memory Pressure Basics in Linux Production IO Bottlenecks and iostat in Production lsof and Open Files in Production Debugging Practical strace Usage in Production Sockets Debugging Tools in Linux Production dmesg and Kernel Signals for Production Debugging Production Debugging Workflow for Linux Systems
Deployment Patterns
Environment and Configuration Management in Production Release Directory Pattern for Safe Linux Deployments Zero-Downtime Restarts in Production Running Migrations Safely in Production Secrets Deploy Patterns in Production Backups and Restore Drills in Production Rollback Strategies for Production Deployments Maintenance Windows in Production Operations Production Deployment Checklist for Linux Systems
Production Checklists
Writing Effective Runbooks for Production Systems Failure Modes Mapping for Linux Production Systems Incident Response Basics for Linux Production Break-Glass Access in Production Capacity Planning Basics for Linux Production Systems Monitoring and Alerting Baseline for Linux Production Production Readiness Review for Linux Systems Configuration Drift in Linux Production Systems Go-Live Checklist

cgroups Basics (CPU/Memory Isolation)

Understand resource control foundations behind containers and systemd slices.
On this page

What Are cgroups?

Control Groups (cgroups) are a Linux kernel feature that limit and isolate resource usage of process groups. They control:

  • CPU usage
  • Memory usage
  • I/O bandwidth
  • Number of processes

Containers (Docker, Kubernetes) rely on cgroups. But cgroups exist even without containers. Production Linux uses them via systemd.

Why cgroups Matter in Production

Without isolation:

  • A memory leak can crash the entire host
  • A batch job can starve your API
  • A runaway process can fork bomb the system

With cgroups:

  • Each service gets defined resource boundaries
  • Blast radius is reduced
  • Incidents are contained

cgroups v1 vs v2

Modern Linux distributions use cgroups v2 (unified hierarchy). You can check: 

mount | grep cgroup

If you see cgroup2, you are using v2.

How systemd Uses cgroups

Every systemd service runs inside a cgroup. You can inspect: 

systemctl status myapp
systemd-cgls

systemd automatically creates slices and scopes.

Limiting CPU with systemd

Inside your unit file: 

[Service]
CPUQuota=50%

This means the service can only use up to 50% of one CPU.

Limiting Memory

[Service]
MemoryMax=500M

If the process exceeds this limit, the kernel can kill it. Better one service dies than the entire host.

Live Inspection

Inspect cgroup paths: 

cat /proc/<pid>/cgroup

Check memory usage (v2 example): 

cat /sys/fs/cgroup/<path>/memory.current

cgroups vs nice

  • nice influences scheduling priority
  • cgroups enforce hard limits

nice is advisory. cgroups are enforcement.

Fork Bomb Protection

You can limit process count: 

[Service]
TasksMax=500

This prevents uncontrolled process spawning.

Production Pattern: Isolate Everything

Good production design:

  • Each service runs in its own cgroup
  • CPUQuota defined for non-critical services
  • MemoryMax defined for untrusted workloads
  • TasksMax set to safe values

Common Production Mistakes

  • Running everything without limits
  • Blaming code when the issue is resource starvation
  • Using nice instead of proper cgroup limits
  • Not monitoring memory.current or pressure

Mental Model

cgroups are containment. They define how much damage a service can do to a host. In production, isolation is more important than raw performance.

Production Checklist

  • Use systemd limits (CPUQuota, MemoryMax, TasksMax)
  • Inspect cgroup assignments during incidents
  • Prefer isolation over shared unlimited resources
  • Monitor memory and CPU pressure per service
Zombies, Orphans, and Stuck Processes →