Linux Process Management for Developers

Understanding Linux process management is essential for debugging performance issues, troubleshooting stuck applications, and optimizing resource usage. Every running program on Linux is a process, and the kernel provides a rich set of tools to inspect, monitor, and control them. This article covers the essential commands and concepts every developer should know.

Inspecting Running Processes

The ps command provides a snapshot of currently running processes. With different options, you can customize the output to show the information most relevant to you. The combination ps aux shows all processes from all users in a detailed format including CPU and memory usage. For real-time monitoring, htop provides an interactive, color-coded interface with tree view, filtering, and the ability to send signals to processes directly. The --sort flag lets you order processes by memory or CPU usage to quickly identify resource hogs.

# List all processes with custom output format
ps -eo pid,ppid,cmd,%mem,%cpu,user --sort=-%mem | head -20

# Show process tree
ps auxf

# Real-time monitoring
htop
# F5: tree view | F4: filter by name | F9: kill process

# Find a specific process by name
pgrep -fl nginx

# Detailed information about a specific PID
ps -fp 1234
ls -l /proc/1234/

The /proc filesystem is a virtual filesystem that exposes kernel data structures as files. Each running process has a directory at /proc/PID/ containing information about its command line (cmdline), environment variables (environ), open file descriptors (fd/), memory mappings (maps), and status (status). Reading these files programmatically is often faster and more flexible than parsing command output.

Systemd Service Management

Modern Linux distributions use systemd as the init system. Services are defined by unit files (.service files in /etc/systemd/system/) and managed with the systemctl command. Systemd handles starting services at boot, restarting them on failure, and collecting their logs through journald. Always check the status of a service before debugging other issues — the status output shows whether the service is running, the last few log lines, and whether it is enabled to start at boot.

# Manage services
systemctl status nginx          # check status and recent logs
systemctl start nginx           # start a service
systemctl stop nginx            # stop a service
systemctl restart nginx         # restart (reload config)
systemctl enable --now docker   # enable at boot and start now

# View logs for a service
journalctl -u nginx -f          # follow logs in real time
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -p err      # only error level and above

# Create a custom service unit
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Python Application
After=network.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/python3 /opt/myapp/main.py
Restart=on-failure
RestartSec=5
EnvironmentFile=/opt/myapp/.env

[Install]
WantedBy=multi-user.target
EOF

Control Groups (cgroups)

Cgroups allow you to limit and account for the resource usage of process groups. Systemd exposes cgroup v2 through service unit properties. You can set CPU quotas, memory limits, and I/O weights to prevent one service from starving others. This is the foundation of container resource limits in Docker and Kubernetes.

# Set resource limits on a systemd service
systemctl set-property myapp.service CPUQuota=50%     # max 50% of one CPU
systemctl set-property myapp.service MemoryMax=512M    # max 512 MB RAM
systemctl set-property myapp.service IOWeight=100      # I/O priority

# View cgroup limits and current usage
systemctl show myapp.service | grep -E 'CPUQuota|MemoryMax|IOWeight'
cat /sys/fs/cgroup/system.slice/myapp.service/memory.current
cat /sys/fs/cgroup/system.slice/myapp.service/cpu.stat

# Check OOM kills
dmesg | grep -i "killed process"
Signals and Killing Processes
Signals are the Linux mechanism for notifying processes of events. The most commonly used signals are SIGTERM (15) — a polite request to terminate, allowing graceful cleanup — and SIGKILL (9) — an immediate forced termination that the process cannot catch or ignore. Always try SIGTERM first and only use SIGKILL as a last resort. The kill command sends signals by PID, while killall and pkill send signals by process name. The SIGHUP signal (1) is often used to tell daemons to reload their configuration without restarting. For background jobs, jobs, fg, and bg let you manage running and suspended processes interactively.
# Send signals
kill -15 1234            # SIGTERM — graceful shutdown
kill -9 1234             # SIGKILL — force kill (last resort)
killall -15 nginx        # SIGTERM all nginx processes
pkill -f "python.*server" # kill by command pattern

# Reload configuration (SIGHUP)
kill -1 1234
systemctl reload nginx   # equivalent for systemd services

# Manage background jobs
sleep 100 &              # start in background
jobs                     # list background jobs
fg %1                    # bring job 1 to foreground
Ctrl+Z                   # suspend foreground job
bg %1                    # resume suspended job in background
The nohup command runs a process that ignores SIGHUP (so it survives terminal closure) and redirects output to nohup.out. This is useful for long-running SSH sessions where you want a process to continue after disconnecting. For more robust background execution, use tmux or screen terminal multiplexers — they create persistent sessions that survive network interruptions and can be reattached later.
Monitoring process health is an ongoing task. Use htop for interactive debugging, systemctl for service management, journalctl for log analysis, and cgroups for resource limits. Combining these tools gives you full visibility into what your system is running and how resources are being consumed.
	

Shell Scripting: Automating System Administration

Shell scripting is the system administrator’s most essential tool. A well-written bash script can automate repetitive tasks, enforce consistency, and save hours of manual work. This article covers the fundamentals of robust shell scripting — error handling, file operations, scheduling, and logging — with practical examples you can adapt immediately.

Writing Robust Scripts

Every production script should start with set -euo pipefail. This combination of options makes bash behave more predictably: -e exits immediately if any command fails (instead of continuing with errors), -u treats unset variables as errors (preventing typos from silently expanding to empty strings), o pipefail makes a pipeline fail if any command in it fails (not just the last one). Without these options, a script might silently continue after a critical failure, leading to corrupted data or inconsistent state.

#!/bin/bash
set -euo pipefail

# Configuration
BACKUP_DIR="/var/backups/$(date +%Y%m%d)"
LOG_FILE="/var/log/backup.log"
RETENTION_DAYS=30

# Logging function
log() {
    local level="$1"
    local message="$2"
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $message" | tee -a "$LOG_FILE"
}

log "INFO" "Starting backup to $BACKUP_DIR"
mkdir -p "$BACKUP_DIR"

# Compress large log files
for file in /var/log/*.log; do
    if [[ -f "$file" && $(stat -c%s "$file") -gt 1048576 ]]; then
        log "INFO" "Compressing $file ($(stat -c%s "$file") bytes)"
        gzip "$file"
    fi
done

log "INFO" "Backup complete"

The log function demonstrates a common pattern: a centralized logging function that adds timestamps, severity levels, and writes to both stdout and a log file using tee -a. This gives you both real-time visibility during manual execution and a persistent log for later review or automated monitoring.

File and Directory Operations

Bash provides powerful file-test operators for checking file properties before operating on them. Always test conditions explicitly with [[ ]] rather than assuming a file exists or a command succeeded. The most useful tests are -f (regular file exists), -d (directory exists), -s (file exists and is non-empty), and -x (file is executable). Use stat for detailed metadata like file size, modification time, and permissions.

# File existence checks
if [[ ! -d "$BACKUP_DIR" ]]; then
    log "ERROR" "Backup directory does not exist"
    exit 1
fi

# Check if file is older than N days
find /tmp -name "*.tmp" -mtime +7 -delete

# Size-based filtering
for f in /data/*.csv; do
    size=$(stat -c%s "$f")
    if [[ $size -gt 100000000 ]]; then  # > 100 MB
        log "WARN" "$f is $size bytes — splitting recommended"
    fi
done

Scheduling with Cron

Cron is the standard job scheduler on Linux. A crontab entry has five time fields (minute, hour, day of month, month, day of week) followed by the command to execute. Always use absolute paths in cron jobs because cron runs with a minimal environment — PATH is often just /usr/bin:/bin. Redirect both stdout and stderr to a log file so that errors are captured. To avoid overlapping executions (if a job takes longer than its interval), use a lock file with flock.

# Crontab format: minute hour day month weekday command

# Run backup daily at 2 AM
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Rotate logs every Sunday at midnight
0 0 * * 0 /usr/local/bin/rotate-logs.sh

# Health check every 5 minutes
*/5 * * * * /usr/local/bin/health-check.sh

# Avoid overlapping runs with flock
0 * * * * /usr/bin/flock -n /tmp/deploy.lock /usr/local/bin/deploy.sh

Error Handling and Notifications

When a scheduled task fails, someone needs to know. Use a notification function that sends alerts via email, Slack webhook, or a monitoring API. Trap the EXIT signal to run cleanup code regardless of how the script exits — whether successfully, by error, or by being killed.

# Trap for cleanup
cleanup() {
    local exit_code=$?
    if [[ $exit_code -ne 0 ]]; then
        log "ERROR" "Script failed with exit code $exit_code"
        curl -X POST -H 'Content-Type: application/json'             -d '{"text": "Backup script failed!"}'             https://hooks.slack.com/services/TOKEN
    fi
    rm -f /tmp/backup.lock
}
trap cleanup EXIT

# Acquire exclusive lock
exec 200>/tmp/backup.lock
flock -n 200 || { log "ERROR" "Another instance is running"; exit 1; }

Well-written shell scripts are the foundation of reliable system administration. By using strict error handling, structured logging, cron scheduling with locks, and notification on failure, you can trust your automation to run correctly — and to alert you immediately when it does not.

Idempotent Scripts and Error Handling

Production shell scripts should be idempotent—running them multiple times produces the same result as once. Use conditional checks before creating files, idempotent commands (mkdir -p, rm -f, cp -n), and cleanup traps that run even on failure. The set -euo pipefail strict mode catches errors. Logging with timestamps creates an audit trail. Provide a –yes or –force flag for CI/CD automation. Validate inputs and check that required tools are installed. These practices make scripts maintainable and safe for automated deployments.

Containerization with Docker on Linux

Docker revolutionized software deployment by packaging applications and their dependencies into lightweight, portable containers. Unlike virtual machines, containers share the host operating system kernel, making them faster to start and far more memory-efficient. This article walks through building a containerized Java application with Docker and orchestrating multi-service setups with Docker Compose.

What Is a Docker Container?

A container is a runtime instance of a Docker image. The image is a read-only template containing the application code, runtime, libraries, and configuration. Docker images are built in layers, where each instruction in the Dockerfile adds a new layer. Layers are cached, so rebuilding after a source change only re-adds the layers that changed. This makes Docker builds both fast and reproducible.

Writing a Dockerfile

The Dockerfile is a recipe that tells Docker how to build your image. Every Dockerfile starts with a FROM instruction that specifies a base image. Choosing a minimal base like Alpine Linux keeps images small — the Eclipse Temurin JDK 21 Alpine image is under 200 MB compared to over 400 MB for the full Ubuntu-based one.

FROM eclipse-temurin:21-jdk-alpine
WORKDIR /app
COPY target/app.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Each line in this Dockerfile has a specific purpose. WORKDIR /app sets the working directory inside the container to /app. COPY target/app.jar . copies the compiled JAR file from the host’s target/ directory into the container’s working directory. EXPOSE 8080 is documentation — it tells anyone running the container that the application listens on port 8080 but does not actually publish the port. ENTRYPOINT defines the command that runs when the container starts. Build the image with docker build -t myapp . and run it with docker run -p 8080:8080 myapp, which maps the host’s port 8080 to the container’s port 8080.

Multi-Stage Builds

For compiled languages like Java or Go, you can use multi-stage builds to keep the final image small. One stage compiles the code using a full SDK image, and a second stage copies only the compiled artifact into a minimal runtime image. This way, build tools like Maven or Gradle are not part of the final image.

# Stage 1: Build
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# Stage 2: Runtime
FROM eclipse-temurin:21-jdk-alpine
WORKDIR /app
COPY --from=build /app/target/app.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

The final image contains only the JRE (or JDK) and the JAR — not Maven, not the source code, and not the Maven cache. This reduces the image from over 1 GB to around 180 MB.

Docker Compose for Multi-Service Applications

Most real-world applications involve multiple services: a web server, a database, a cache, and perhaps a message queue. Docker Compose lets you define all services in a single compose.yaml file and start them with one command: docker compose up.

services:
  web:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
    environment:
      - DATABASE_URL=jdbc:postgresql://db:5432/mydb

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret

volumes:
  pgdata:

The depends_on field ensures the database service starts before the web service. Services communicate over an internal Docker network using their service names as hostnames — so the web app connects to db:5432 instead of localhost:5432. The volumes section creates a named volume pgdata that persists the database data across container restarts, preventing data loss when the container is recreated.

Useful Docker Commands

# List running containers
docker ps

# View logs from a container
docker logs -f myapp

# Execute a command inside a running container
docker exec -it myapp sh

# Clean up unused resources
docker system prune -af

# Inspect image layers
docker history myapp:latest

Docker containers are ephemeral by design — treat them as disposable. Store state in volumes or external services. With this approach, you can deploy, scale, and update applications reliably across any Linux server, from your laptop to a production Kubernetes cluster.

Docker Networking and Security

Docker networking has three built-in drivers: bridge (default, isolated network per container group), host (container uses host network stack), and overlay (multi-host networking for Docker Swarm). For security, run containers as non-root users, drop Linux capabilities, use read-only root filesystems, and enable Content Trust to verify image signatures. Use Docker Bench Security to audit container configurations. Multi-stage builds separate build dependencies from runtime dependencies—the final image only contains the compiled binary and minimal runtime libraries, reducing both attack surface and deployment time.

Docker Compose and Development Workflows

Docker Compose defines multi-container applications in a docker-compose.yml file, enabling one-command startup of the entire development environment (web server, database, cache, message queue). Compose features include: dependency-based startup order (depends_on with health checks), environment variable files (.env), named volumes for persistent data, network configuration for service discovery, and health checks for container readiness. The compose watch feature (Docker Compose 2.23+) automatically syncs file changes and rebuilds containers, enabling hot-reloading development workflows. For testing, Compose can spin up test infrastructure (test databases, mock services) alongside test suites, then tear everything down with docker compose down. Profiles in Compose allow starting different service subsets for development vs. production-like testing.