Linux
Beginner 12 min read Linux

Linux Architecture

Understand the layered architecture of a Linux system — hardware, kernel, system libraries, utilities and the shell — and how they cooperate to run every application.

kernelshellsystem callsglibcuser spacekernel spacedevice driversarchitecture
Prerequisites: Introduction to Linux
Introduction

What is this?

Linux is built from stacked layers. At the bottom sits the hardware — CPU, RAM, disks and network cards. On top of it runs the kernel, the core that manages resources and talks to hardware through device drivers. Above the kernel are system libraries (glibc, OpenSSL), system utilities (ls, grep, systemctl), then the shell (bash, zsh, fish) and finally user applications like nginx, Docker or vim. Each layer only talks to the ones directly above and below it, which keeps the design clean and portable.

Motivation

Why do you need it?

  • Separation of concerns: the kernel handles the hard, privileged work while applications stay simple and portable.
  • Portability: because applications talk to libraries, not hardware, the same program runs on ARM, x86 and cloud VMs.
  • Stability: a crash in user space doesn't take down the kernel, so one bad app rarely kills the server.
  • Security: privilege separation means only the kernel talks to hardware — apps must ask permission via system calls.
Think about it

Mental model

Imagine

A restaurant with a kitchen and a wait staff

Think of

The layered Linux model

Customers (applications) order through waiters (the shell). The kitchen (kernel) uses its tools (device drivers) to cook. If one waiter drops a plate (an app crashes), the kitchen keeps running — the two are separated by a wall (the system-call boundary).

Mechanics

How it works

  • Hardware is controlled exclusively by the kernel through device drivers; apps never touch hardware directly.
  • The kernel provides process management (scheduling, multitasking), memory management, filesystem and network management.
  • Applications request work through system calls such as open(), read(), write() and fork(), which the kernel validates and executes.
  • System libraries like glibc wrap those raw syscalls into friendly functions, and utilities like ls and grep build on the libraries.
  • The shell is a command interpreter: it reads your line, expands it, launches a program and shows you the output.

The stack of a Linux machine and where each layer lives.

User Applications
Shell
System Libraries
System Utilities
Linux Kernel
Hardware
Reference

Key commands

uname -r

Show the kernel release version.

6.5.0-1020-aws
uname -a

Show full kernel and machine details.

Linux host 6.5.0-1020-aws x86_64 GNU/Linux
type ls

Show what kind of command ls is and where it lives.

ls is aliased to 'ls --color=auto'
which nginx

Show the path to a binary.

/usr/sbin/nginx
ldd /usr/bin/ls

List the shared libraries a binary needs.

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
hostnamectl

Show kernel, OS and hostname info.

Hands-on

Examples

Trace a simple command through the architecture

Trace a simple command through the architecture
# What the shell does when you type 'ls'
type ls                      # where does ls live? (a system utility)
file /usr/bin/ls             # what kind of binary is it?
ldd /usr/bin/ls              # which system libraries does it link?
 
# Watch a command touch the kernel
strace -c ls /etc 2>&1 | tail -5   # which syscalls did it make?
 
# Which kernel handles you right now
uname -r                     # kernel release
hostnamectl                  # kernel + OS info

The shell finds the ls binary, which loads glibc into memory and calls kernel syscalls to read the directory. strace reveals exactly those syscalls, making the invisible architecture visible.

Real world

In production

  • Troubleshooting starts with the layer in question: app code (user space), libraries, or the kernel itself via dmesg.
  • Choosing the right kernel tune-ups (sysctl) and container runtimes is a core platform-engineering skill.
  • Understanding syscalls helps you read strace output to find slow I/O, blocked network calls or app hangs.
  • Security hardening (SELinux, AppArmor, seccomp) is applied at the kernel boundary between app and OS.
Guidelines

Best practices

  • Start debugging at the right layer: strace for app syscalls, dmesg for kernel, top/vmstat for resources.
  • Keep the kernel patched: run unattended-upgrades and track your distro's security advisories.
  • Prefer distro-packaged binaries over hand-rolled ones so library versions stay consistent.
  • Read /proc and /sys as the kernel's 'control panel' instead of guessing from third-party tools.
Watch out

Common mistakes

  • Blaming the kernel when the app is at fault — check dmesg before assuming a kernel bug.
  • Installing random .deb/.rpm files that break the shared library versions your system depends on.
  • Forgetting that containers share the host kernel — a container is user space, not a separate OS.
  • Running every daemon as root, bypassing the privilege model the architecture was built around.
Root cause analysis

Common issues

Error
no such file or directory when running a binary
Root cause

A shared library the binary needs is missing, or the ELF interpreter is absent.

Fix

Run ldd <binary> to find the missing library and install the package that provides it.

Error
Application hangs and never returns
Root cause

The app is blocked on a syscall (I/O, network, lock) inside the kernel.

Fix

Use strace -p <pid> to see which syscall is blocked, then fix the underlying resource.

Error
Kernel OOM: Out of memory killer killed my process
Root cause

Memory pressure made the kernel pick a victim process to reclaim RAM.

Fix

Check dmesg | grep -i oom, raise memory limits, add swap, or reduce app memory use.

When things break

Debugging tips

  • strace -p <pid> attaches to a running process to watch its syscalls live.
  • dmesg | tail surfaces kernel ring-buffer messages after crashes or OOM kills.
  • vmstat 1 and top show whether the bottleneck is CPU, memory or I/O.
  • ldd <binary> reveals missing or mismatched shared libraries.
Interviews

Interview checkpoint

Practice

Hands-on lab

Explore the Linux layers hands-on
15 min · beginner
In progress
Objectives
  • Identify the running kernel and its release
  • Inspect user-space utilities, libraries and the shell
  • Trace system calls made by a simple command
  • Map each observation back to its layer

Explore the Linux layers hands-on

15 min · beginner

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/6
1

Which layer of a Linux system manages processes, memory and device drivers?

2

What is the shell's role in the architecture?

3

How do applications request work from the kernel?

4

Which layer is glibc part of?

5

A user application can access hardware directly without the kernel's involvement.

6

A process appears hung. Which tool lets you watch its live system calls?

Quick reference

Cheat sheet

Kernel & system info
uname -rKernel release
uname -aAll kernel/machine details
cat /proc/versionKernel build string
hostnamectlKernel + OS overview
dmesg | tailRecent kernel messages
User space inspection
echo $SHELLYour default shell
type <cmd>Kind of command (alias/binary/builtin)
which <cmd>Path to a binary
ldd <binary>Linked shared libraries
strace -p <pid>Trace a process's syscalls
strace -c <cmd>Summarise syscall counts
Kernel state as files
cat /proc/meminfoMemory stats
cat /proc/uptimeSystem uptime
cat /proc/cpuinfoCPU details
ls /proc/<pid>Everything about a process
Go deeper

Official documentation

The Linux Kernel documentation
docs
Linux man pages — syscalls
docs
glibc manual
docs
Advanced Bash-Scripting Guide
docs