Linux OS and Fundamentals

Linux is the layer that turns hardware into process isolation, files, sockets, memory mappings, timers, signals, device drivers, and resource accounting. Developers need it because code eventually becomes processes, syscalls, pages, sockets, and file descriptors. Operators need it because incidents show up as CPU pressure, memory pressure, IO waits, scheduler latency, kernel logs, device-driver behavior, access failures, broken scheduled jobs, SSH lockouts, and host identity drift.

Concrete commands, configs, and failure patterns are embedded in the topic pages where the operating-system behavior appears: systemd examples live with systemd pages, firewall examples live with netfilter pages, cgroup examples live with containerization and memory pages, and packet-performance examples live with the kernel networking pages.

Mental Model

A Linux system is a set of cooperating boundaries:

The kernel is not only “the thing under user space.” It is the shared arbiter for memory, CPU, IO, devices, and security boundaries.

Critical Subtopics

Unless a page is explicitly distro-neutral, examples prefer Debian-family Linux with Ubuntu Server as the default operational target. That means apt, dpkg, systemctl, journalctl, Netplan, UFW, /etc/ssl/certs, update-ca-certificates, OpenSSH, sudo, timedatectl, and systemd timers are the expected baseline tools.

Processes, Forking, Exec, and Wait

A Linux process is an execution context with a PID, virtual address space, file descriptor table, credentials, signal dispositions, and scheduling state.

Common lifecycle:

1. A process calls fork() or clone() to create a child.
2. The child often calls execve() to replace its memory image with a new program.
3. The parent calls wait() or waitpid() to reap the child exit status.

fork() is efficient because Linux uses copy-on-write memory. The child does not immediately copy all parent memory. Instead, parent and child initially share physical pages as read-only. If either writes, the kernel copies the modified page.

Important process states:

Zombies do not consume CPU or normal memory, but they consume PID table slots. Many zombies mean the parent is not reaping children.

File Descriptors

File descriptors point at open files, sockets, pipes, eventfds, epoll instances, devices, and more. Many production failures are FD failures:

• process hits ulimit -n,
• system hits global file table pressure,
• app leaks sockets,
• logs rotate but process keeps old deleted file open,
• child processes inherit FDs that should have had close-on-exec.

Useful commands:

ls -l /proc/<pid>/fd
lsof -p <pid>
ulimit -n
cat /proc/sys/fs/file-nr

CPU and Scheduler Basics

High CPU means runnable work is consuming CPU time. High load average means tasks are runnable or in uninterruptible sleep. Those are not identical.

What to separate:

• User CPU: application code.
• System CPU: kernel work on behalf of processes.
• IO wait: CPU idle while tasks wait for IO.
• Steal: virtual CPU time taken by the hypervisor.
• Softirq: deferred network/block/kernel work.

nice affects CPU scheduling priority for normal tasks. Real-time policies can starve normal tasks if misused.

High CPU workflow:

uptime
mpstat -P ALL 1
top -H -p <pid>
pidstat -t -p <pid> 1
perf top
cat /proc/pressure/cpu

First determine whether the CPU is in user code, kernel code, interrupts/softirqs, or virtualization steal. Then drill into process, thread, syscall, or interrupt source.

RAM, Virtual Memory, and Caches

Linux memory accounting is often misunderstood. “Free memory” being low is normal because Linux uses RAM for page cache and buffers. Cache can usually be reclaimed when applications need memory.

Key terms:

Memory workflow:

free -h
cat /proc/meminfo
vmstat 1
slabtop
ps aux --sort=-rss | head
cat /proc/pressure/memory
dmesg -T | grep -i -E 'oom|out of memory|killed process'

Do not clear caches as a routine “fix.” It can make performance worse by forcing rereads. Clear cache only for controlled experiments when you understand what you are measuring.

Paging, Swap, and Memory Pressure

Paging is moving pages between memory states: active, inactive, file-backed, anonymous, swapped, reclaimed. Swap is not automatically bad. It can improve system behavior by moving cold anonymous pages out of RAM. Swap storms are bad: the system spends most time moving pages instead of doing useful work.

Signs of dangerous memory pressure:

• rising si/so in vmstat,
• high memory PSI,
• direct reclaim latency,
• OOM kills,
• application latency during GC/allocation,
• cgroup memory events increasing.

Container warning: cgroup memory limits include more than just app heap. Page cache, tmpfs, and some kernel accounting can matter. A container can OOM while the host still has plenty of memory.

Kernel Parameters and sysctl

Kernel parameters are configured in a few places:

• boot-time kernel command line: /proc/cmdline,
• runtime sysctls: /proc/sys/...,
• persistent sysctl files: /etc/sysctl.conf and /etc/sysctl.d/*.conf,
• module parameters: /sys/module/<module>/parameters/...,
• systemd unit limits and cgroup controls.

Common sysctl areas:

Treat sysctl changes as production changes: document the reason, observe before/after, and know whether the workload is host-level or cgroup-limited.

sysctl vm.swappiness
sysctl -a | grep '^vm\.'
cat /proc/cmdline
cat /sys/module/amdgpu/parameters/* 2>/dev/null

cgroups, Containers, and systemd

Modern Linux systems use cgroups to account and limit CPU, memory, IO, PIDs, and other resources. systemd uses cgroups for services; containers use cgroups for isolation.

Important signals:

• CPU quota throttling can look like mysterious latency.
• Memory limits can OOM a service even when host memory is available.
• PID limits can prevent fork/exec.
• IO limits can make a service slow without high CPU.
• Pressure Stall Information (PSI) shows time lost waiting on CPU, memory, or IO pressure.

systemctl status <service>
systemd-cgls
systemd-cgtop
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

GPU Interactions: General Model

Linux GPU stacks involve PCIe enumeration, kernel modules, firmware, device files, display or compute userspace, and sometimes container runtime hooks. GPU incidents often cross user/kernel boundaries. An application may report CUDA, ROCm, Vulkan, OpenGL, or display errors, while the root cause is kernel driver mismatch, missing firmware, permissions, PCIe reset, thermal throttling, or device memory pressure.

General GPU checks:

lspci -nnk | grep -A3 -E 'VGA|3D|Display'
ls -l /dev/dri /dev/nvidia* 2>/dev/null
dmesg -T | grep -i -E 'drm|gpu|amdgpu|nvidia|xid'
lsmod | grep -E 'amdgpu|nvidia'

For deeper AMD, NVIDIA, ROCm, CUDA, Secure Boot, containers, nvidia-smi, and NVIDIA persistence mode details, see Linux GPU Drivers.

High CPU Runbook

1. Check system shape: uptime, top, mpstat -P ALL 1.
2. Determine user vs system vs IO wait vs steal.
3. If one process dominates, inspect threads: top -H -p <pid>.
4. If system CPU is high, inspect syscalls, perf, interrupts, and network softirq.
5. If load is high but CPU is not, look for D-state tasks and IO stalls.
6. Check cgroup CPU throttling for containers and systemd services.
7. Preserve evidence before restarting.

High RAM Runbook

1. Check free -h and /proc/meminfo.
2. Separate application RSS, page cache, slab, tmpfs, and cgroup memory.
3. Check vmstat 1 for swap activity.
4. Check PSI memory pressure.
5. Look for OOM kills in dmesg.
6. For a process, inspect /proc/<pid>/smaps_rollup.
7. For containers, inspect cgroup memory events and limits.
8. Avoid clearing caches unless testing a hypothesis.

Commands

uname -a
cat /proc/cmdline
ps -eo pid,ppid,stat,comm,%cpu,%mem --sort=-%cpu | head
free -h
vmstat 1
mpstat -P ALL 1
pidstat -durh 1
cat /proc/pressure/{cpu,memory,io}
dmesg -T | tail -100

Study Cards

Practice Deck

References

• Linux kernel sysctl VM documentation
• Linux kernel cgroup v2 documentation
• Linux kernel Pressure Stall Information
• proc(5) Linux manual page
• fork(2) Linux manual page
• execve(2) Linux manual page
• wait(2) Linux manual page
• Linux kernel AMDGPU documentation
• NVIDIA driver persistence documentation
• Linux GPU drivers
• Linux boot and userspace
• Linux kernel modules and devices
• Linux filesystems and IO
• Linux block devices and partitioning
• Linux mounts and fstab
• Linux mount namespaces and propagation
• ext4, XFS, and filesystem repair
• RAID, multipath, and device mapper
• Linux storage health and performance
• Linux network stack
• Linux kernel network performance
• Linux TCP kernel tuning
• Linux sockets and IPC
• Linux processes and threads
• Debian and Ubuntu operations
• Users, permissions, and sudo
• SSH access
• Logs and observability
• Scheduled automation
• Time, hostname, and identity
• Linux LVM
• systemd
• systemd networking
• systemd socket activation and network services
• resolv.conf