When you type ls -la and hit Enter, the shell (bash/zsh) reads that string. First it checks if it's a built-in command (like cd, echo). If not, it searches through directories listed in your PATH environment variable — one by one — until it finds a binary named ls.

Once found, the shell calls fork() — cloning itself into a parent and child process. The child process then calls exec() — which replaces the child's entire memory with the ls program. The parent shell calls wait() — pauses itself until the child finishes. When ls is done, the child exits, and the parent wakes up and shows you the prompt again.

This fork-exec pattern is the foundation of how every command runs in Linux. Even when you run a Python script — the shell forks, the child execs the Python interpreter, Python interpreter runs your script, exits, shell resumes.

In Linux, a process is what the kernel gives its own virtual address space, file descriptor table, and PID. When you run python script.py, that's a process. Each process is isolated — one crashing doesn't kill others.

A thread (called a "light-weight process" in Linux) lives inside a process. All threads share the heap, code segment, and open files. They each have their own stack and CPU registers. Creating a thread is much cheaper — no new address space needed. Communication is just reading/writing shared memory — but that needs locks or you'll have race conditions.

When a child process exits, it doesn't disappear immediately. The kernel keeps a tiny record of it in the process table — its PID, exit status, resource usage — waiting for the parent to come and collect this info via wait() or waitpid(). Until the parent does that, the child sits as a zombie — it's done running, uses no CPU or memory, but its PID slot is occupied.

A handful of zombies is normal. Thousands of zombies means the parent is badly written — never calling wait(). This exhausts PIDs (Linux has a finite PID limit, typically 32768). Fix: fix the parent code, or kill the parent (which makes zombies orphans, adopted by init/systemd, which properly reaps them).

Daemons are the workhorses of Linux. They start when the system boots (managed by systemd or older init) and keep running silently. sshd waits for SSH connections. crond runs scheduled jobs. nginx or apache serves web pages. syslogd collects logs.

To become a daemon, a process typically: forks and lets the parent exit (so the shell thinks the job is done), calls setsid() to detach from the terminal (no controlling TTY), closes stdin/stdout/stderr (redirects them to /dev/null or a log file), changes working directory to / (so it doesn't block unmounting any filesystem).

Every file in Linux has an inode — a data structure holding the file's metadata and location on disk. The filename is just a label pointing to an inode. A hard link creates another filename pointing to the exact same inode. Both names are equal — neither is "the original." The file data is only deleted when ALL hard links to it are removed (inode reference count hits 0).

A soft link (symlink) is a special file that contains a path string — like a shortcut. When you access a symlink, Linux follows the path inside it to the target. Delete the target? The symlink still exists but points to nothing — a "dangling symlink." Soft links can cross filesystems and point to directories; hard links cannot.

Think of a filesystem like a library. The book content is stored on shelves (data blocks). The catalog card for each book is the inode — it tells you who wrote it (owner), when it was last read (timestamps), how many pages (size), and which shelf it's on (data block pointers). The book's title is just a label in a directory that points to the catalog card number (inode number).

Every file and directory has exactly one inode. Directories are just files containing a list of (filename → inode number) mappings. When you access /home/user/file.txt, Linux traverses: root inode → home directory inode → user directory inode → file.txt's inode → reads data blocks. Filenames live in directories, not in inodes. That's why hard links work — two names, one inode.

Linux file permissions have three levels: owner (the user who owns the file), group (members of the file's group), and others (everyone else). Each level gets three possible permissions: read (4), write (2), execute (1). Add them up to get the octal digit.

So 755: Owner = 4+2+1 = 7 (full control). Group = 4+0+1 = 5 (read and run, can't modify). Others = 4+0+1 = 5 (read and run, can't modify). This is the standard permission for executables and web directories — everyone can read and run, only owner can modify.

kill PID sends SIGTERM (signal 15). This is a request, not a demand. A well-written program catches SIGTERM, closes database connections, flushes logs, releases locks, then exits cleanly. A process can even ignore SIGTERM if it wants — which is why sometimes kill doesn't work on a stubborn process.

kill -9 PID sends SIGKILL (signal 9). This one the kernel handles directly — the process never even sees it. No cleanup happens. No signal handlers run. File handles may not be flushed, temp files not deleted, database connections abruptly cut. Use it as the last resort when kill doesn't work.

These three tools do completely different things and people often mix them up. grep looks through file content — give it a pattern and files, it prints matching lines. find walks the directory tree looking for files matching criteria — name, permissions, size, modification time. locate queries a database (built by updatedb, runs nightly) of all filenames — blazing fast but won't find files created today until updatedb runs again.

Output redirection is how you save command output to files instead of printing to screen. > is destructive — it opens the file, truncates it to zero, then writes. If the file doesn't exist, it's created. If it does exist, all previous content is gone. >> opens the file at the end and appends — previous content is safe.

The pipe is one of Linux's most elegant ideas. Instead of running a command, saving output to a file, running next command on that file — you just connect them directly. The kernel sets up an in-memory buffer between them. The first command writes to it, the second reads from it. They run concurrently — producer and consumer.

This Unix philosophy of small, focused tools that do one thing well and chain via pipes is why Linux command line is so powerful. cat reads, grep filters, sort sorts, uniq deduplicates, wc counts — combine them any way you need.

Think of RAM as your desk and swap as a filing cabinet. When your desk is full, you move less-used papers to the filing cabinet to make room. You can still access them — just much slower (you have to get up, walk to the cabinet, find the paper). Swap works the same way — the kernel moves cold memory pages to a swap partition or swap file on disk. This prevents out-of-memory crashes, but performance tanks heavily when you're swapping a lot (called "thrashing").

Modern SSDs make swap less painful but still nowhere near RAM speeds. A server running on swap is a server in trouble — it means you're out of RAM and need to add memory or kill memory-hungry processes.

Linux is smart about memory. A lot of "used" RAM is actually the page cache — disk data cached in RAM for speed. When memory is needed, the kernel first reclaims this cache — it can always re-read from disk. This is why free -h often shows very little "free" memory on a healthy system — Linux uses all available RAM for caching. That's normal and good.

If reclaiming cache isn't enough, Linux starts swapping — moving inactive process memory pages to disk. Performance degrades. If swap is also exhausted — the OOM Killer (Out of Memory Killer) activates. It scores every process by memory usage, importance, and other factors, and kills the highest-scoring one. This is a last resort. Often it kills your app server instead of a less important process — a painful production incident.

TCP (Transmission Control Protocol): Before sending any data, TCP does a 3-way handshake (SYN → SYN-ACK → ACK) to establish a connection. Every packet sent must be acknowledged by the receiver. Lost packets are retransmitted. Packets arrive in order. This reliability costs time — extra round trips, more overhead. Use TCP when data integrity matters: HTTP/HTTPS, SSH, databases, file transfers.

UDP (User Datagram Protocol): Just send packets — no connection setup, no acknowledgment, no retransmission, no ordering guarantees. It's fast and has minimal overhead. If a packet is lost, it's lost — the application layer has to handle it if it cares. Use UDP when speed beats reliability: live video streaming, online gaming, DNS queries, VoIP calls (a dropped frame in video is fine — waiting for retransmission ruins the experience).

HTTP (HyperText Transfer Protocol) is the language browsers and servers use to talk. The problem: everything is sent in plaintext. Your login credentials, credit card numbers, session cookies — all visible to anyone doing a man-in-the-middle attack on a public WiFi network. Packet capture tools like Wireshark make this trivial.

HTTPS adds a TLS (Transport Layer Security) layer. Before any HTTP data flows, TLS does a handshake — client verifies the server's certificate (issued by a trusted CA like Let's Encrypt), they negotiate an encryption algorithm and exchange keys, and from then on all data is encrypted. Even if someone captures the packets, they see gibberish.

Before SSH, people used Telnet to connect to remote servers — username, password, all commands sent completely in plaintext. Anyone on the network could sniff the traffic and steal your password. SSH (1995) fixed this with strong encryption. Every byte between your terminal and the server is encrypted.

SSH also supports key-based authentication — even more secure than passwords. You generate a key pair: private key stays on your laptop, public key goes on the server's ~/.ssh/authorized_keys. When you connect, SSH proves you have the private key (without sending it) using a cryptographic challenge-response. No password transmitted, and even if someone has your public key, they can't log in without your private key.

Every Linux system has the crond daemon running in the background. Every minute it checks the crontab files to see if any job is due. If yes — it runs the command. It's how sysadmins automate: backup every night at 2 AM, clean temp files every week, check disk space every hour and alert if nearly full, rotate logs daily.

Every process in Linux inherits environment variables from its parent. When you start a shell, it inherits from its parent, and passes them to commands it runs. This is how you pass configuration to programs without hardcoding it — database connection strings, API keys, feature flags, Java home directory, Python paths.

PATH is the most important environment variable. It's a colon-separated list of directories. When you type ls, the shell searches /usr/local/bin, then /usr/bin, then /bin, etc. — whichever comes first in PATH wins. Adding a directory to PATH makes any executables in it available as commands.

fork() duplicates the calling process — same code, same memory (using copy-on-write, so it's efficient), same file descriptors, but a new PID. Fork returns 0 in the child process and the child's PID in the parent — this is how you know which process you're in. At this point, both parent and child are running the same code.

exec() (actually a family: execv, execve, execl...) replaces the current process image with a new program. The process keeps its PID, file descriptors, and environment, but its memory (code, stack, heap) is completely replaced by the new program. After exec(), the old program's code is gone — only the new program runs.

This two-step design is intentional. The gap between fork and exec gives you a chance to set up the child's environment — redirect file descriptors, set up pipes, change user permissions — before replacing it with the target program.

This is the most important question for any backend/DevOps role. Interviewers want to see that you have a systematic approach — not guessing randomly. There's a clear order of operations. Don't jump to checking application logs before confirming the server is even reachable. That's wasted time in a real incident.

Think in layers: Network → OS → Process → Application → Data. Each layer needs to be ruled out before going deeper. And always communicate — in a real incident, you're not working in silence. You're updating your team every few minutes: "Server is reachable, SSH works, checking process status now."