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

systemd Unit Types Overview

service, socket, timer, target, mount: what each unit does and why it matters.
On this page

Why systemd Matters in Production

On modern Linux systems, systemd is PID 1. It is responsible for starting, stopping, supervising, and restarting services. If you do not understand systemd, you are not managing production Linux — you are just running processes.

What Is a Unit?

systemd manages resources using unit files called units. Each unit represents something systemd can manage: a service, a socket, a timer, a mount, a device, or a grouping target. In production, thinking in units (instead of raw processes) makes operations predictable.

Most Common Unit Types (Production View)

.service — Background Services

The unit type you will use most. It defines how to start/stop a long-running process and how to supervise it. Examples: nginx, php-fpm, your API, a worker, a queue consumer. 

systemctl status nginx
systemctl status myapp

.socket — Socket Activation

A socket unit can listen on a port or UNIX socket and start the related service only when traffic arrives. Benefits: faster boot, on-demand start, and better resource usage for rarely-used services.

Production use case: internal admin tools, low-traffic daemons, or services you want to auto-start on connection.

.timer — Scheduled Tasks (Cron Alternative)

Timers replace cron with better reliability:

  • Can run missed jobs after reboot (Persistent=true)
  • Integrates with journald logging
  • Supports jitter/random delays to avoid thundering herds
systemctl list-timers

.target — Grouping and Boot Stages

Targets are not “processes”. They group units and represent system states. Example: multi-user.target is a common “server is up” target.

Production use case: bring up a whole stack by binding units to a target.

.mount / .automount — Mount Management

systemd can manage mounts and even mount on-demand with automount. This is safer than random startup scripts, especially for network filesystems.

.path — Trigger on Filesystem Changes

A path unit can watch a directory/file and trigger a service when something changes. Production use case: drop a file into a directory → a service consumes it.

.slice / .scope — Resource Isolation and One-Off Jobs

systemd uses cgroups under the hood:

  • slice: group of services with shared resource policy
  • scope: externally started processes that systemd starts tracking

Production use case: enforce CPU/memory limits per service, isolate noisy neighbors on the same host.

Where Unit Files Live

  • /usr/lib/systemd/system/ (package-provided; do not edit)
  • /etc/systemd/system/ (your overrides and custom units)

How to Inspect Units Fast

systemctl list-units --type=service --state=running
systemctl list-unit-files | head
systemctl status myapp --no-pager
systemctl cat myapp

Common Production Mistakes

  • Managing processes with kill/nohup instead of systemd units
  • Editing vendor unit files under /usr/lib instead of overriding in /etc
  • Using cron for everything and losing logs/observability
  • Not understanding that After= is ordering, not readiness

Mental Model

systemd is the supervisor and policy engine of the host. If you want reliability, you define behavior as units: startup, restart, dependencies, limits, logging.

Production Checklist

  • Know the key unit types: service, timer, socket, target
  • Use /etc/systemd/system for overrides/custom units
  • Prefer timers over cron for reliability + journald logs
  • Inspect units with systemctl status/cat/show
Service Unit Best Practices →