144 Linux Interview Questions and Answers (2026)

User space and kernel space are two privilege domains: kernel space runs trusted code with full hardware access (ring 0), while user space runs applications in a restricted, isolated context (ring 3). The separation protects the system from buggy or malicious programs, and processes cross the boundary only through controlled entry points.

• Kernel space: Privileged CPU mode with direct access to hardware, memory, and scheduling; the kernel, drivers, and core services live here.

• User space: Unprivileged mode where each process has its own virtual address space and cannot touch hardware or other processes' memory directly.

• Why the separation exists:

  • Isolation and stability: a crashing app can't take down the kernel or corrupt other processes.

  • Security: privileged operations are mediated, so untrusted code can't bypass access control.

• How a process crosses the boundary:

  • Via a system call: a software trap (e.g. syscall instruction) switches the CPU to kernel mode at a fixed entry point.

  • Also involuntarily through interrupts and exceptions (hardware IRQ, page fault); the kernel runs, then returns control to user mode.

"Everything is a file" means Linux exposes most resources through the same file abstraction (a path with a file descriptor) so the same syscalls (open, read, write, close) work across radically different things. This gives a uniform, composable interface for hardware, kernel data, and I/O channels.

• Hardware devices:

  • Device files under /dev represent hardware: /dev/sda (a disk), /dev/tty (a terminal), /dev/null (a sink).

  • Reading/writing these files sends data to or from the driver.

• Network sockets: A socket is referenced by a file descriptor, so you read/write it like a file (with extra calls like send/recv for socket-specific options).

• Kernel and process state: Pseudo-filesystems /proc and /sys expose process info and kernel tunables as readable/writable files.

• Nuance: It's really "everything is a file descriptor"; the abstraction is the uniform descriptor-based I/O, not that every object is a byte stream on disk.

The kernel is the core program that manages hardware and processes; a distribution is the kernel plus all the software, tools, and packaging that make a usable operating system.

• The Linux kernel:

  • A single project (maintained by Linus Torvalds and contributors) that handles scheduling, memory, drivers, filesystems, and system calls.

  • By itself it isn't usable: no shell, no package manager, no userland utilities.

• A Linux distribution:

  • Bundles the kernel with GNU userland (coreutils, bash), a package manager, init system, and defaults.

  • Examples: Debian, Ubuntu, Fedora, Arch. They differ in packaging, release cadence, and philosophy, not the kernel itself.

• Key point: many distributions can ship the same kernel version; the distro is the curation and integration layer around it.

uname

A shell variable lives only in the current shell process; an environment variable is a shell variable that has been exported so it is copied into the environment of child processes. The difference is scope: local to the shell versus inherited by everything the shell launches.

• Shell variable:

  • Set with VAR=value; visible only to the current shell and its own commands.

  • Not passed to child processes; list them with set.

• Environment variable:

  • Created with export VAR; inherited by any process the shell forks.

  • List them with env or printenv.

• Inheritance is one-way: A child gets a copy; changing it in the child never affects the parent.

Running source script.sh executes the script in your current shell, so its variable and directory changes persist; running ./script.sh launches a new child shell that runs the script and then exits, discarding its changes.

• source (or .):

  • No new process; commands run in the current shell.

  • Variables, cd, aliases, and functions defined by the script remain afterward.

  • Used to load config like ~/.bashrc or environment files.

• ./script.sh:

  • Forks a child process (needs execute permission and a #! shebang).

  • Changes it makes vanish when the child exits.

• Rule of thumb: source to modify your current environment; execute to run a self-contained task in isolation.

PATH is a colon-separated list of directories the shell searches, in order, whenever you type a command name without a slash. The shell scans each directory left to right and runs the first matching executable it finds.

• How the search works:

  • For a bare name (ls), the shell checks each PATH directory in order and stops at the first hit.

  • Order matters: an earlier directory shadows a same-named binary later.

  • Names containing a / (like ./script.sh) bypass PATH entirely.

• Performance detail: Bash caches resolved locations; hash -r clears the cache if a binary moves.

• Inspect and extend it:

  • See where a command resolves with which cmd or type cmd.

  • Add a directory with export PATH="$HOME/bin:$PATH".

• Security note: never put . (current directory) early in PATH, as it lets a local malicious binary override real commands.

Command substitution runs a command in a subshell, captures its standard output, strips trailing newlines, and inserts that text into the enclosing command line before it executes.

• Two syntaxes:

  • $(...) is modern and preferred: it nests cleanly and is easier to read.

  • `...` (backticks) is the old form: nesting requires escaping backslashes and it is error-prone.

• How it works:

  • The inner command runs in a subshell; only its stdout is captured (not stderr).

  • Trailing newlines are removed, and the result undergoes word splitting and globbing unless quoted.

• Always quote the result: Use "$(...)" to preserve spaces and newlines and avoid re-splitting.

They are all command interpreters, but differ in standards compliance and interactive features: sh is the minimal POSIX standard, bash is the ubiquitous feature-rich default, zsh adds power-user interactivity, and fish prioritizes friendliness at the cost of POSIX compatibility.

• sh (POSIX shell): The portable standard; scripts targeting #!/bin/sh run nearly anywhere. Often a link to dash or bash in POSIX mode.

• bash: The de facto Linux default: adds arrays, [[ ]], brace expansion, and more while staying largely POSIX-compatible.

• zsh: Mostly bash-compatible with richer completion, globbing, and theming (popular via Oh My Zsh). Default on modern macOS.

• fish: Best out-of-the-box UX (autosuggestions, syntax highlighting) but intentionally not POSIX-compliant, so many scripts need rewriting.

• Rule of thumb: Write scripts for sh/bash for portability; pick zsh or fish for interactive comfort.

Globbing is the shell's filename-matching syntax: the shell expands wildcard patterns into a list of matching pathnames before running the command. It is simpler and different from regular expressions, which are a general text-matching language used by tools like grep and sed.

• Common glob patterns:

  • * matches any run of characters; ? matches exactly one character.

  • [abc] or [a-z] matches one character from a set or range.

• The shell does the expansion:

  • The command never sees *.txt; it sees the already-expanded filenames.

  • If nothing matches, bash by default passes the literal pattern through (unless nullglob is set).

• Key differences from regex:

  • Meaning differs: glob * means "any characters", but regex * means "zero or more of the previous atom".

  • Globs match whole filenames and are much less expressive; regex has quantifiers, anchors, and alternation.

  • Globbing is done by the shell on pathnames; regex is done by programs on arbitrary text.

The exit status is an integer (0-255) a command returns when it finishes, stored in $?, that reports whether it succeeded. By convention 0 means success and any nonzero value means failure.

• The basic convention:

  • 0 = success; nonzero = an error, where the specific number can distinguish failure types.

  • $? always holds the status of the most recently completed foreground command.

• Reserved and special values:

  • 126: command found but not executable; 127: command not found.

  • 128+N: terminated by signal N (e.g. 130 is Ctrl+C / SIGINT).

• Why it matters:

  • Control operators use it: && runs on success, || runs on failure.

  • Scripts should exit N with meaningful codes so callers can react.

$EDITOR is an environment variable that tells programs (git, crontab, sudoedit) which text editor to launch when they need you to edit something. vi/vim are powerful modal editors with a learning curve, while nano is a simpler modeless editor that is easier for beginners.

• What $EDITOR does:

  • Programs read it to decide which editor to spawn; set it in your shell profile, e.g. export EDITOR=vim.

  • $VISUAL is a related variable preferred for full-screen editors; many tools check it first.

• vi / vim:

  • Modal: separate normal, insert, and command modes; you switch with keys like i and Esc.

  • Save/quit with :wq; extremely powerful once learned, and installed almost everywhere as vi.

• nano:

  • Modeless: you just type, and shortcuts are shown at the bottom (^O to save, ^X to exit).

  • Lower ceiling but far gentler for quick edits.

• Rule of thumb: Learn enough vi to survive on any server; use nano for casual editing.

A pipe connects the output of one process to the input of another process; a redirection connects a stream to a file. Pipes pass data between commands in memory, while redirection reads from or writes to files on disk.

• Pipe (|): Connects the stdout of the left command to the stdin of the right command via a kernel buffer, with both running concurrently.

• Redirection (>): Sends a stream to a file: > truncates/creates, >> appends, and it involves the filesystem rather than another process.

• Data flow of cat file | grep 'error' > log.txt:

  1. cat file writes the file's contents to its stdout.

  2. The pipe feeds that into grep 'error' as its stdin.

  3. grep's stdout is redirected to log.txt, so matching lines land in the file instead of the terminal.

• Note: this is a useless use of cat; grep 'error' file > log.txt does the same thing.

Every process starts with three standard streams identified by file descriptors: stdin (0) for input, stdout (1) for normal output, and stderr (2) for error/diagnostic output. Separating stdout from stderr lets you route them independently.

• stdin (fd 0): The input stream, by default the keyboard, redirectable with <.

• stdout (fd 1): Normal program output, by default the terminal.

• stderr (fd 2): Error and diagnostic messages, kept separate so they aren't swallowed by pipes or output redirection.

• Redirect only errors to a file: Use 2> to target fd 2 alone, leaving fd 1 on the screen.

2>&1 redirects stderr (fd 2) to wherever stdout (fd 1) currently points. The & means "the file descriptor," not a file named 1.

• Meaning: Make fd 2 a copy of fd 1's current target, merging errors into the normal output stream.

• Order matters:

  • In command > file 2>&1, stdout is pointed at the file first, then stderr copies that target, so both go to the file.

  • command 2>&1 > file is different: stderr copies the terminal before stdout is redirected, so errors stay on screen.

• Modern shorthand: In Bash, command &> file redirects both streams to a file at once.

tee reads from stdin and writes to both stdout and one or more files at once, splitting a pipeline like a T-junction. It's useful when you want to save intermediate output and keep passing it down the pipe.

• What it does: Duplicates the stream: the data continues to the next command while a copy is written to disk.

• Common uses:

  • Log the output of a stage while viewing it live.

  • Append instead of overwrite with tee -a.

  • Write to a root-owned file from a non-root pipeline: echo x | sudo tee /etc/file (since > is opened by the unprivileged shell).

grep searches input line by line for lines matching a pattern and prints them. The variants differ in which regex dialect they use: basic (BRE) versus extended (ERE).

• Basic usage: grep 'pattern' file prints matching lines; useful flags: -i (ignore case), -r (recursive), -v (invert), -n (line numbers), -c (count).

• grep (BRE): Basic regex where +, ?, {}, and | are literal unless escaped as \+, \?, etc.

• egrep and grep -E (ERE): Extended regex where those metacharacters work without backslashes; egrep is just the deprecated alias for grep -E.

• Rule of thumb: Prefer grep -E for readable alternation and quantifiers; use -F (fixed strings) when the pattern has no regex at all.

tar is an archiver (bundles many files into one, preserving metadata) but does not compress; gzip is a compressor that shrinks a single stream but doesn't archive; zip does both at once. tar is combined with gzip to get archiving plus compression on Unix.

• tar (Tape ARchive):

  • Concatenates files into one stream and preserves permissions, ownership, symlinks, and timestamps.

  • No compression by itself: a .tar is roughly the sum of its inputs.

• gzip: Compresses a single stream with DEFLATE; produces one .gz, so it pairs naturally with tar's single output.

• zip:

  • Archives and compresses each file independently, so you can extract one file without reading the whole archive; common on Windows.

  • Per-file compression usually gives worse ratios than tar+gzip, which compresses the whole stream and exploits redundancy across files.

• Why tar + gzip:

  • tar handles bundling + metadata, gzip handles compression: separation of concerns following the Unix philosophy.

  • Result is .tar.gz / .tgz; tar invokes gzip directly via -z.

• Trade-off: solid tar.gz compresses better but random access is costly; zip trades ratio for per-file access.

SIGTERM is a polite, catchable request to shut down that lets a process clean up; SIGKILL is a forcible, uncatchable termination handled entirely by the kernel. Prefer SIGTERM first, escalate to SIGKILL only if it won't die.

• SIGTERM (signal 15, the default of kill):

  • Can be caught, handled, or ignored: the process can flush buffers, close files/sockets, and exit gracefully.

  • A well-behaved daemon uses its handler to release resources.

• SIGKILL (signal 9):

  • Cannot be caught, blocked, or ignored; the kernel terminates the process immediately.

  • No cleanup runs, so you risk leftover temp files, locks, or corrupted state.

• When to use each:

  • Default to SIGTERM for graceful shutdown.

  • Use SIGKILL only for hung/unresponsive processes that ignore SIGTERM.

  • SIGKILL can't kill a process stuck in uninterruptible sleep (state D, e.g. blocked on I/O) until it wakes.

In top, CPU percentage is summed across cores, so 100% equals one fully-used core: 150% means one and a half cores' worth of work, and 400% means four cores fully saturated by a multithreaded process.

• Percentage is per-core, not capped at 100%:

  • A process with multiple threads/processes running in parallel accumulates usage across the cores it occupies.

  • 400% means roughly four cores busy at once, so the workload is genuinely parallel.

• What it tells you about the hardware:

  • The machine has at least that many logical CPUs (cores or hardware threads).

  • Seeing 400% implies 4+ available cores; you can't exceed (number of cores × 100%).

• Tip: press 1 in top to show per-core breakdown, or use Irix/Solaris mode toggle (I) to switch between summed and normalized views.

Suspend the process with Ctrl-Z, then resume it in the background with bg; this detaches it from the terminal's foreground while keeping it running.

• Ctrl-Z: Sends SIGTSTP, stopping (pausing) the foreground job; it is now suspended, not running.

• bg: Resumes the stopped job in the background so it continues running while you get your prompt back.

• fg: Brings a background or stopped job back to the foreground, reconnecting it to the terminal.

• Reference jobs by number: bg %1, fg %2; list them with jobs.

All three send signals, but they differ in how you target processes: kill targets by PID, while pkill and killall target by name (with different matching rules).

• kill:

  • Sends a signal to a specific PID (or job spec): kill -9 1234.

  • Default signal is SIGTERM (15), a polite request to exit.

• pkill:

  • Matches by name using a pattern (substring/regex) and can filter by user, terminal, etc.

  • Example: pkill -f 'python app.py' matches against the full command line.

• killall:

  • Matches by exact process name and signals every instance: killall nginx.

  • Stricter matching than pkill (whole name, not substring).

• Caution: name-based tools can hit unintended processes; verify first with pgrep before killing.

Both let you run commands with another user's privileges (usually root), but su switches into a full shell as that user, while sudo runs a single command under a fine-grained, audited policy. sudo is preferred because it grants precise, logged access without sharing the root password.

• su (substitute user):

  • Requires the target account's password (the root password for su -).

  • Opens a persistent shell with that user's full privileges: all-or-nothing.

• sudo:

  • Authenticates with your own password, authorized by rules in /etc/sudoers.

  • Can restrict a user to specific commands, and every invocation is logged.

• Why sudo wins in production:

  • No shared root password: revoke access by editing sudoers, not by rotating a password everyone knows.

  • Accountability: the audit log ties each privileged action to a real user.

  • Least privilege: grant just the commands needed instead of a root shell.

Least privilege means every user, service, and process should have only the permissions strictly required to do its job, and no more. It limits the blast radius when an account is compromised or makes a mistake.

• Applied to user accounts:

  • Don't log in or run apps as root; use a normal account and escalate narrowly via sudo.

  • Grant specific sudo commands instead of full root, and use groups to scope file access.

• Applied to services: Run each daemon under its own dedicated, unprivileged system account (e.g. www-data) so a compromised service can't touch unrelated files.

• Why it matters:

  • Contains damage: a breached low-privilege account can't own the whole system.

  • Reduces accidental destruction and makes auditing meaningful.

Linux permissions are three sets of three bits: read (r), write (w), and execute (x) for the owner, the group, and others. Octal notation encodes each set as a single digit by summing r=4, w=2, x=1, so 755 means rwxr-xr-x.

• The three classes: Owner (user), group, and others, shown left to right in ls -l.

• The three permissions:

  • On files: r=read contents, w=modify, x=run as a program.

  • On directories: r=list names, w=create/delete entries, x=enter/traverse.

• Octal mapping (r=4, w=2, x=1):

  • 7 = 4+2+1 = rwx; 5 = 4+1 = r-x; 6 = 4+2 = rw-.

  • So 755 = owner rwx, group and others r-x; 644 = rw-r--r--.

  • A leading fourth digit encodes special bits (setuid=4, setgid=2, sticky=1), as in 1777.

They all change file metadata, but on different attributes: chmod changes permission bits, chown changes the owning user (and optionally group), and chgrp changes only the owning group.

• chmod (change mode):

  • Sets read/write/execute bits for user, group, other. Symbolic (chmod u+x file) or octal (chmod 755 file).

  • Also controls special bits: setuid, setgid, sticky.

• chown (change owner):

  • Reassigns the owning user; chown user:group file sets both at once.

  • Typically requires root, since giving away files has security implications.

• chgrp (change group):

  • Changes only the group; equivalent to chown :group file.

  • A non-root owner can use it only for groups they belong to.

• Rule of thumb: ownership (who) via chown/chgrp, access (what they can do) via chmod.

A hard link is a second directory entry pointing to the same inode (the actual file data), while a symbolic link is a small separate file containing a path to another name. Deleting the original leaves a hard link fully working, but breaks a symlink.

• Hard link:

  • Shares the same inode number, so both names are equal peers referencing one set of data blocks.

  • Data is freed only when the inode's link count drops to zero (all names removed).

  • Cannot span filesystems and normally cannot link directories.

• Symbolic (soft) link:

  • A distinct inode whose content is a pathname; it points by name, not by inode.

  • Can cross filesystems and link directories.

  • Created with ln -s target linkname (hard link is ln target linkname).

• If the original is deleted:

  • Hard link: data survives; the link count just decreases and you still read/write through the remaining name.

  • Symlink: becomes dangling (broken), pointing to a path that no longer exists; access fails.

The Filesystem Hierarchy Standard (FHS) is a specification that defines the standard directory layout of Linux/Unix systems, so software and admins can predict where files live. Broadly, /etc holds static host-specific configuration, while /var holds variable data that changes as the system runs.

• Purpose of FHS:

  • Consistent, predictable paths across distributions for programs, packagers, and users.

  • Separates static vs variable and shareable vs host-specific data.

• /etc:

  • System-wide, host-specific configuration files (text), e.g. /etc/fstab, /etc/passwd, /etc/ssh/.

  • Should contain no binaries; meant to be relatively static.

• /var: Variable data that grows/changes at runtime: logs (/var/log), spools/queues (/var/spool), caches, and /var/lib (application state like databases).

• Other common ones: /bin, /usr (read-only shareable programs), /tmp (transient), /home (user data).

The /etc/fstab file (filesystem table) is a static configuration file listing filesystems and how they should be mounted, so they can be mounted automatically at boot and by simple mount commands.

• What it controls:

  • Which device/filesystem mounts where at boot, with which type and options.

  • Enables mount -a and shorthand like mount /data using its entries.

• The six fields per line:

  1. Device: often by UUID= or LABEL= for stability across renumbering.

  2. Mount point (e.g. /, /home).

  3. Filesystem type (ext4, xfs, nfs).

  4. Mount options (defaults, noatime, ro).

  5. dump: backup flag (usually 0).

  6. fsck pass order (0 skip, 1 root, 2 others).

• Caution: a bad entry can block boot; prefer UUIDs and test with mount -a before rebooting.

mount attaches a filesystem (on a device or image) to a directory in the unified tree (the mount point) so its contents become accessible; you do it manually with the command, or persistently by declaring it in /etc/fstab.

• What it does: Grafts a block device's filesystem onto a directory; the kernel then routes I/O under that path to the device.

• Manual (temporary): Runs immediately but is lost on reboot; umount detaches it.

• Persistent (across reboots):

  • Add an entry to /etc/fstab; use a stable identifier like UUID= rather than /dev/sdX which can change.

  • Test with mount -a before rebooting to catch typos that could break boot.

Linux treats almost everything as a file, and the first character of ls -l output encodes the file type, letting you distinguish regular files, directories, links, sockets, pipes, and device nodes at a glance.

• - regular file: ordinary data or executable.

• d directory: a file mapping names to inodes.

• l symbolic link: a pointer to another path (shown as name -> target).

• s socket: an endpoint for inter-process communication (e.g. a Unix domain socket).

• p FIFO/named pipe: a pipe with a filesystem name for one-way IPC.

• Device files:

  • b block device: buffered, addressed in blocks (disks).

  • c character device: unbuffered, stream-oriented (terminals, /dev/null).

• Tools: file inspects content type, and ls -l or stat report the type flag.

Starting a service and enabling it are two independent actions: start runs it right now in the current session, while enable creates the boot-time symlinks so it launches automatically on future boots.

• Start now (does not survive reboot): systemctl start nginx activates the unit immediately.

• Enable at boot (does not start now): systemctl enable nginx links the unit into its WantedBy target so it starts on boot.

• Do both at once: systemctl enable --now nginx enables and starts in one command.

• Verify and reverse: systemctl is-enabled nginx and systemctl status nginx check state; disable and stop are the inverses.

You set the timezone and clock behavior with timedatectl and the system locale with localectl (or by editing /etc/locale.conf); timedatectl is the systemd tool for querying and configuring the system clock, timezone, and NTP sync.

• Timezone: timedatectl set-timezone Europe/Berlin updates the /etc/localtime symlink; list options with timedatectl list-timezones.

• What timedatectl reports:

  • Local and UTC time, RTC time, timezone, and whether NTP synchronization is active.

  • Enable time sync with timedatectl set-ntp true.

• Locale:

  • localectl set-locale LANG=en_US.UTF-8 sets language/encoding; it controls formatting, sorting, and messages.

  • Keyboard layout is also handled via localectl set-keymap.

/var/log is the conventional directory holding system and application log files, and rsyslog is the daemon that receives log messages and routes them to the right files (or remote servers) based on rules.

• Typical contents of /var/log:

  • syslog or messages: general system messages.

  • auth.log / secure: authentication and sudo activity.

  • kern.log: kernel messages; dmesg for the ring buffer.

  • Service-specific subdirs like /var/log/nginx/ or /var/log/journal/.

• Role of rsyslog:

  • Listens for messages (from apps via the syslog API, from journald, or over the network).

  • Uses facility and severity rules in /etc/rsyslog.conf to decide where each message goes.

  • Can forward logs to a central log server for aggregation.

Cron is a time-based job scheduler daemon (crond) that runs commands automatically at fixed times or intervals defined in a crontab file. A crontab line has five time fields followed by the command.

• The five fields (in order):

  1. minute (0-59)

  2. hour (0-23)

  3. day of month (1-31)

  4. month (1-12)

  5. day of week (0-7, where 0 and 7 both mean Sunday)

• Special characters: * means every value; */5 means every 5th; 1-5 a range; 1,15 a list.

• Managing it: crontab -e edits, crontab -l lists; system-wide jobs live in /etc/crontab and /etc/cron.d/.

• Shortcuts like @daily, @reboot, and @hourly replace the five fields.

Use ss -ltnp (or the equivalent netstat flags) to list listening TCP sockets with the owning process, then filter for the port.

• With ss (preferred, faster):

  • Run ss -ltnp 'sport = :8080' or simply ss -ltnp | grep :8080.

  • Flag meaning: -l listening, -t TCP, -n numeric ports, -p show process (pid/name).

• With netstat: Run netstat -ltnp | grep :8080 (same flag semantics).

• You usually need root: Without sudo, the PID/program column may be blank for processes you don't own.

• Alternative: lsof -i :8080 or fuser 8080/tcp also map a port to a PID.

Both transfer data over HTTP(S) and more, but curl is a flexible single-shot request/API client that defaults to stdout, while wget is a downloader built for saving files and recursive mirroring.

• curl:

  • Prints to stdout by default; a library-backed tool (libcurl) supporting many protocols (HTTP, FTP, SMTP, etc.).

  • Excellent for testing APIs: set methods, headers, and bodies (-X, -H, -d) and inspect responses (-i, -v).

• wget:

  • Saves to a file by default and shines at bulk/unattended downloads.

  • Built-in recursive mirroring (-r, -m), automatic retries, and easy resume (-c).

• Rule of thumb: Reach for curl to interact with an API or script HTTP calls; reach for wget to grab files or mirror a site.

/etc/passwd holds world-readable account attributes, while /etc/shadow holds the sensitive hashed passwords and aging data, readable only by root: the split protects hashes from ordinary users.

• /etc/passwd (readable by all):

  • Colon-separated fields: username, password placeholder (x), UID, GID, GECOS/comment, home directory, and login shell.

  • The x indicates the real hash lives in /etc/shadow.

• /etc/shadow (root-only, mode 640/600):

  • Username, the hashed password (with algorithm and salt, e.g. $6$ for SHA-512), and password-aging fields.

  • Aging fields: last change, min/max age, warning period, inactivity, and expiration.

• Why the split exists: Many tools need passwd data (UID/name mapping), so it stays readable; hashes are quarantined so unprivileged users can't run offline cracking.

useradd is the low-level, universal binary for creating accounts, while adduser is a friendlier high-level wrapper (a Perl script on Debian/Ubuntu) that prompts interactively and sets sensible defaults.

• useradd:

  • Present on essentially all Linux distros; low-level and non-interactive, ideal for scripts.

  • Often needs explicit flags to be useful: -m (create home), -s (shell), -G (supplementary groups).

• adduser:

  • Debian/Ubuntu convenience wrapper: interactively creates the home directory, copies skeleton files, and prompts for a password.

  • Not guaranteed on non-Debian systems (e.g. RHEL), so scripts favor useradd.

• Adding a user to a group:

  • Append without removing existing memberships: usermod -aG groupname user (omitting -a replaces all supplementary groups).

  • The user must re-login for new group membership to take effect.

You generate a key pair with ssh-keygen, keep the private key secret, and place the public key in the server's ~/.ssh/authorized_keys: the server challenges you to prove possession of the private key without ever transmitting a secret over the wire.

• Generate the pair:

  • ssh-keygen -t ed25519 -C "you@host" creates a private key (id_ed25519) and public key (id_ed25519.pub).

  • Prefer ed25519 (or a large RSA key); protect the private key with a passphrase.

• Install the public key: ssh-copy-id user@host appends it to the server's authorized_keys with correct permissions.

• How the handshake works: The server encrypts a challenge (or verifies a signature) against your public key; only the matching private key can respond, so the secret never leaves your machine.

• Why keys beat passwords:

  • No reusable secret crosses the network and there's nothing to phish or brute-force at the login prompt.

  • Keys are long and high-entropy, resisting guessing; enables passwordless automation and can be centrally revoked.

  • An ssh-agent caches the decrypted key so you enter the passphrase once per session.

They operate at different layers: dpkg is the low-level tool that installs a single .deb file, while apt is the high-level front end that talks to repositories and resolves dependencies for you (ultimately calling dpkg).

• dpkg: the package installer:

  • Installs/removes an individual .deb you already have on disk.

  • Does NOT fetch or resolve dependencies: a missing dependency leaves the package unconfigured.

  • Good for querying too: dpkg -l, dpkg -L pkg.

• apt: the dependency-aware manager:

  • Downloads from repos, resolves and installs dependencies automatically.

  • Handles upgrades: apt update then apt upgrade.

• When to use each:

  • Use apt for everyday installs from repos.

  • Use dpkg -i for a standalone .deb, then run apt install -f to pull in any missing dependencies.

dmesg prints the kernel ring buffer: an in-memory, fixed-size circular log where the kernel records messages from boot and runtime, such as hardware detection, driver events, and errors.

• What the ring buffer is:

  • A bounded circular buffer in kernel memory; when full, oldest messages are overwritten, so it's not permanent history.

  • Available very early in boot, before userspace logging is up.

• Typical contents:

  • Hardware and driver initialization, device plug/unplug (USB), disk and filesystem events.

  • Kernel warnings, OOM-killer actions, segfaults, and network interface state.

• Useful options:

  • dmesg -T for human-readable timestamps; dmesg -w to follow new messages live; dmesg -l err to filter by priority.

  • On systemd systems, journalctl -k shows the same kernel messages with persistence across boots.

System calls are the kernel's published API: the controlled entry points a user-space program uses to request privileged services (I/O, memory, process control) that it cannot perform itself. They are the boundary through which every interaction with the kernel flows.

• What they provide: Access to resources the kernel guards: files (open, read), processes (fork, execve), memory (mmap), networking (socket).

• How the interface works:

  • The program places a syscall number and arguments in registers, then executes a trap instruction (syscall on x86-64) that switches to kernel mode.

  • The kernel dispatches via the syscall table, validates arguments, does the work, and returns a result (or negative error code) to user space.

• Why an interface, not direct access: It enforces permission checks and isolation, and keeps a stable contract so user programs don't depend on kernel internals.

• Usually wrapped: Programs rarely invoke the trap directly; glibc wrapper functions handle the register setup and error reporting via errno.

A system call is a request into the kernel that crosses the user/kernel privilege boundary, while a standard library function call is ordinary user-space code that runs in your process without a mode switch. The key difference is privilege transition and cost: syscalls trap into the kernel; library calls do not (unless they internally make one).

• System call:

  • Executes a trap that switches to kernel mode to perform a privileged operation.

  • Relatively expensive: mode switch plus argument validation; e.g. write, read, open.

• Library function call: A normal function jump within user space; no privilege change, cheap. e.g. strlen, strcpy.

• The overlap:

  • Many library functions wrap syscalls: printf formats in user space then calls write.

  • Libraries can add value like buffering: fwrite batches data so fewer write syscalls happen.

• How to observe: Use strace to see the actual syscalls a program makes; pure library calls won't appear.

A context switch is when the kernel saves the state of the currently running task and restores the state of another, so the CPU can move from executing one thread of control to another. It's how Linux gives the illusion of many things running at once on limited cores, but it has a real cost.

• What gets saved/restored: CPU registers, program counter, and stack pointer; if switching to a different process, also the memory mapping (page tables / CR3).

• When it happens:

  • Time-slice expiry driven by the scheduler, a higher-priority task becoming runnable, or a task blocking on I/O.

  • Also on interrupts and syscalls that require rescheduling.

• Why it's costly: Direct cost of saving/loading state, plus indirect cost from cache and TLB misses after the switch (especially between processes).

• Process vs thread switch: Switching between threads in the same process is cheaper: they share the address space, so no page-table swap and less TLB flushing.

In Linux, a process and a thread are both represented by the same kernel structure (a task, task_struct); the difference is what resources they share. A process has its own address space, while threads of a process share that address space and other resources. Both are just tasks to the scheduler.

• Process:

  • Has its own virtual memory, file descriptor table, and PID; isolated from other processes.

  • Created with fork(), which copies the address space (copy-on-write).

• Thread:

  • Shares address space, open files, and signal handlers with sibling threads; has its own stack, registers, and thread ID.

  • Cheaper to create and switch between than processes.

• The unifying mechanism: Both are created via clone(); flags like CLONE_VM, CLONE_FILES decide what is shared. A "thread" is just a task sharing more.

• Scheduling: The scheduler operates on tasks, so threads and processes are scheduled the same way; threads within a process are grouped under a shared thread-group ID (the PID).

Block and character devices are the two main classes of Linux device files, distinguished by how data is accessed. Block devices are addressed in fixed-size blocks and support random access with kernel buffering; character devices are accessed as a sequential stream of bytes, typically unbuffered.

• Block device:

  • Reads/writes in fixed blocks and supports seeking to arbitrary positions (random access).

  • Goes through the kernel's buffer cache / block layer for caching and I/O scheduling.

  • Examples: disks and partitions like /dev/sda; usually hold filesystems.

• Character device:

  • Byte-stream access, generally sequential and without block buffering.

  • Examples: terminals /dev/tty, serial ports, /dev/random, /dev/null.

• How to tell them apart:

  • In ls -l, the type field shows b for block and c for character.

  • Both are identified by major/minor numbers that map to the driver.

Unix is the original 1970s operating system family and a set of design standards; Linux is a free, independently written kernel that follows those standards but shares no original Unix code.

• Origin:

  • Unix came from AT&T Bell Labs; commercial descendants include Solaris, AIX, and HP-UX.

  • Linux was written from scratch by Linus Torvalds in 1991, inspired by Unix but not derived from its code.

• Standards vs implementation: "Unix" is a trademark and certification (POSIX/Single UNIX Specification); Linux is "Unix-like": largely POSIX-compliant but not certified.

• Licensing and cost: Traditional Unix was proprietary and vendor-tied; Linux is open source under the GPL and runs on commodity hardware.

• Practical takeaway: skills transfer well (shell, filesystem hierarchy, tools), but Linux and Unix are separate lineages.

The Linux kernel is licensed under the GPLv2, a copyleft license: anyone can use, modify, and distribute it, but distributed modifications must also be released under the GPL with source available.

• Copyleft (share-alike): If you distribute a modified kernel, you must provide the corresponding source under the same license. This prevents proprietary forks of the kernel.

• GPLv2 specifically: The kernel is deliberately kept at GPLv2 (not "v2 or later"), so it cannot be upgraded to GPLv3.

• The userspace boundary:

  • A syscall exception clarifies that normal user programs calling the kernel are not "derived works," so your app doesn't become GPL just by running on Linux.

  • Loadable kernel modules that link tightly to the kernel are the gray area (the debate over proprietary drivers and EXPORT_SYMBOL_GPL).

• Significance: it guaranteed improvements flow back to the community, driving broad vendor collaboration and preventing fragmentation into closed variants.

A login shell is started when you authenticate (console login, SSH), while a non-login shell is any subsequent shell you open without re-authenticating (a terminal window in a GUI, or typing bash). They differ mainly in which startup files they read.

• Login shell:

  • Started by login, SSH, or bash --login; usually the first shell in a session.

  • Reads /etc/profile, then the first found of ~/.bash_profile, ~/.bash_login, or ~/.profile.

• Non-login (interactive) shell:

  • A new terminal or subshell that doesn't authenticate.

  • Reads ~/.bashrc (and often /etc/bash.bashrc).

• Common convention: Because login shells skip ~/.bashrc, people source it from ~/.bash_profile so both get the same setup.

• Check with shopt login_shell or echo $0 (a leading - indicates a login shell).

The shell parses your input, finds the ls executable, forks a child process, and has that child replace itself with the program via exec, while the shell waits for it to finish.

• Read and parse: The shell reads the line, does tokenizing, expansions (globbing, variables, substitution), and splits into command plus arguments.

• Resolve the command: It checks aliases, functions, and builtins first; otherwise it searches each directory in $PATH for an executable named ls.

• Create the process:

  • fork() creates a child copy of the shell.

  • The child calls execve() to load the ls binary, replacing its memory image.

• Run and reap:

  • ls writes to stdout (the terminal), then exits.

  • The shell, blocked in wait(), collects the exit status into $? and shows the prompt again.

A child process inherits only the exported (environment) variables of its parent; plain shell variables stay local to the shell. export marks a variable so it is placed into the environment passed to future child processes.

• Two kinds of variables:

  • Shell (local) variables: visible only in the current shell, not passed down.

  • Environment variables: copied into every child's environment at exec time.

• What export does:

  • It flags a variable for inheritance; children get a copy, not a shared reference.

  • A child cannot change the parent's environment: changes flow one way, parent to child.

• Inheritance is a snapshot: Exporting after a child started does not affect the already-running child.

• Per-command environment: Prefixing VAR=value cmd sets it just for that one command's environment.

sed (stream editor) transforms text as it streams through, applying editing commands line by line without opening an interactive editor. Its most common job is find-and-replace substitution.

• What it's for: Non-interactive editing: substitution, deletion, insertion, and printing selected lines in scripts and pipelines.

• Substitution syntax s/pattern/replacement/flags:

  • s is the substitute command; without flags it replaces only the first match per line.

  • The g flag replaces all matches on each line; i makes it case-insensitive.

• Editing files: By default sed writes to stdout; -i edits the file in place (-i.bak keeps a backup).

awk is a pattern-action language for processing structured, column-oriented text. It automatically splits each line into fields ($1, $2, ...) and runs your logic per line, making it ideal for extracting, computing, and reformatting tabular data.

• Core model: It works as pattern { action }: for each line matching the pattern, run the action; $0 is the whole line, NF the field count, NR the line number.

• Best suited for:

  • Selecting or reordering columns, filtering rows on field conditions, and summing or averaging numeric columns.

  • Reports with BEGIN and END blocks for headers and totals, plus variables and arrays for aggregation.

• Where it fits versus others: Use grep to just match, sed for simple substitutions, and awk when you need fields plus arithmetic or logic.

find walks a directory tree recursively, testing each entry against filters (name, type, size, time, permissions), and can run actions on matches; piping its output to xargs batches those results into arguments for another command.

• How find evaluates:

  • Syntax is find <path> <tests> <actions>; tests like -name, -type f, -mtime -1, -size +100M are ANDed by default.

  • Built-in actions: -print (default), -delete, and -exec cmd {} \; (runs once per file) or -exec cmd {} + (batches files).

• Combining with xargs:

  • xargs reads items from stdin and appends them as arguments, packing many into few command invocations (faster than one-per-file).

  • Handle spaces/newlines safely with find ... -print0 | xargs -0: null-delimited names avoid word-splitting bugs.

• -exec + vs xargs: both batch; xargs adds control (-P for parallelism, -n for chunk size).

A zombie (defunct) process is one that has finished executing but whose exit status hasn't yet been read by its parent, so its entry lingers in the process table. It's already dead, so signals do nothing; it's removed only when the parent reaps it.

• What it is:

  • On exit, the kernel frees the process's memory but keeps a minimal entry holding its PID and exit code until the parent collects it.

  • Shows as state Z or <defunct> in ps.

• Why SIGKILL doesn't work:

  • Signals target running processes; a zombie has no code executing, so there is nothing to kill.

  • It occupies only a table slot, not CPU or memory.

• How to actually remove it:

  • The parent must reap it by calling wait() / waitpid(); a common trigger is sending the parent SIGCHLD.

  • If the parent is buggy and won't reap, kill the parent: the zombie is re-parented to init/systemd (PID 1), which reaps it automatically.

• A few zombies are harmless; many indicate a parent that never reaps, which can exhaust PIDs.

fork() creates a new process by duplicating the caller; exec() replaces the current process's program image with a new one. Together they are how Unix launches a new program: fork, then exec in the child.

• fork():

  • Creates a child that is a copy of the parent; child gets a new unique PID, parent keeps its own.

  • Memory is duplicated logically but shared copy-on-write: pages are only physically copied when one side writes.

  • Returns twice: 0 in the child, the child's PID in the parent.

• exec():

  • Loads a new executable into the existing process, replacing code, data, heap, and stack.

  • The PID stays the same: it's the same process running a different program.

  • On success it does not return (there's nothing to return to); open file descriptors typically survive.

• The combined pattern: Shell/parent calls fork(), child calls exec() to run the target, parent wait()s for it.

An orphan is a still-running process whose parent has died; a zombie is a finished process whose exit status hasn't been reaped. The key difference: an orphan is alive and needs a new parent, a zombie is dead and needs to be collected.

• Orphan process:

  • Parent exited first while the child keeps running: the child is fully functional, just parentless.

  • It's immediately re-parented (adopted) so someone can eventually reap it.

• Zombie process:

  • Already terminated; only its process-table entry (PID + exit code) remains until the parent calls wait().

  • Consumes no CPU/memory, just a table slot.

• Who adopts the orphan:

  • Traditionally PID 1 (init) adopts orphans and reaps them.

  • On modern systemd systems, a process can register as a subreaper (via prctl(PR_SET_CHILD_SUBREAPER)): user services are re-parented to their managing systemd --user or service scope rather than always PID 1.

• Link between them: an unreaped orphan becomes a zombie briefly, but its adopter reaps it automatically.

Niceness is a per-process hint to the scheduler about how willing a process is to yield CPU to others. It ranges from -20 (most favorable, highest priority) to +19 (least favorable); a higher nice value means the process gets a smaller share of CPU under contention.

• The scale:

  • -20 = greedy/high priority, +19 = generous/low priority; default is 0.

  • Only root can lower niceness (raise priority); any user can raise it (be nicer).

• Effect under the CFS (Completely Fair Scheduler):

  • CFS translates the nice value into a weight; CPU time is allocated proportionally to weight.

  • Each nice step changes weight by roughly 1.25x, so a difference of 10 gives about a 10x CPU-share difference.

  • It's relative: nice only matters when processes actually compete: an idle CPU still runs a +19 process at full speed.

• Setting it:

  • nice -n 10 cmd starts a process with a nice value; renice changes a running one.

  • Niceness affects CPU scheduling only; for I/O priority use ionice.

Both are terminal-generated signals, but SIGINT asks a process to terminate while SIGTSTP merely suspends it so it can be resumed later.

• SIGINT (Ctrl+C, signal 2):

  • Default action is to terminate the process.

  • Catchable and ignorable: programs can install a handler to clean up or refuse to quit.

• SIGTSTP (Ctrl+Z, signal 20):

  • Default action is to stop (suspend) the process, not kill it.

  • The process becomes a stopped job that you resume with fg or bg.

  • Also catchable (unlike SIGSTOP, which cannot be caught).

• Key contrast: Ctrl+C ends work, Ctrl+Z pauses it while keeping the process in memory.

SIGKILL (and SIGSTOP) are handled directly by the kernel and are deliberately non-overridable, so a process can always be forcibly removed regardless of its state or bugs.

• It is a guaranteed kill switch: If any process could trap or ignore SIGKILL, a runaway or malicious process could make itself unkillable.

• The kernel acts, not the process:

  • The signal disposition table blocks registering a handler for SIGKILL; the kernel reaps the process without ever running its code.

  • No cleanup runs (no destructors, no flushing buffers), which is why it can leave locks or temp files behind.

• Exception: a process in D (uninterruptible sleep) won't die until its kernel operation completes, because it isn't in a state to be reaped yet.

Both keep a job alive after logout by breaking its dependence on the terminal: nohup shields a command from the SIGHUP hangup signal at launch, while disown removes an already-running job from the shell's job table.

• The problem they solve: When you log out, the shell sends SIGHUP to its jobs, which normally terminates them.

• nohup command &:

  • Runs the command ignoring SIGHUP, and redirects output to nohup.out since the terminal may go away.

  • Used at start time, before the process exists.

• disown:

  • Applied to an existing job (often after Ctrl-Z + bg): removes it from the shell's job list so no SIGHUP is sent on exit.

  • Use disown -h to keep the job listed but mark it to ignore hangup.

• For full detachment (surviving logout plus reattach later), tools like tmux or screen are more robust.

SIGHUP (signal 1) originally meant "hangup": the controlling terminal was lost. Long-running daemons have no terminal, so they repurpose SIGHUP as a convention meaning "re-read your configuration without restarting."

• Original meaning: Sent when a terminal disconnects; by default it terminates foreground processes.

• Why daemons reuse it for reload:

  • A daemon detached from any terminal will never legitimately receive a real hangup, so the signal is free to be given a custom meaning.

  • Reloading via SIGHUP keeps the process (and its PID, open sockets, listening ports) alive, avoiding downtime that a full restart would cause.

• How it works in practice:

  • The daemon installs a handler that re-parses config files and reopens log files.

  • Reopening logs on SIGHUP is why log-rotation tools send it after moving a log file.

  • Trigger it with kill -HUP <pid> or systemctl reload <service>.

The sticky bit on a directory restricts deletion so that only a file's owner (or the directory owner or root) can remove or rename it, even when everyone has write access to that directory. It's what makes a world-writable shared space like /tmp safe.

• The problem it solves:

  • Write permission on a directory normally lets you delete any file in it, because deletion is a directory operation, not a file operation.

  • Without it, any user could delete or replace another user's files in /tmp.

• What it does: Deletion/rename is limited to the file's owner, the directory's owner, or root.

• How to see and set it:

  • Shows as t in the others-execute slot: drwxrwxrwt.

  • Set with chmod +t dir or chmod 1777 dir.

The umask is a mask of permission bits to remove from the base permissions the OS assigns to newly created files and directories. It doesn't set permissions directly; it subtracts them.

• The base defaults: Files start from 666 (rw for all), directories from 777 (execute needed to enter them).

• How the mask applies:

  • Final permission = base AND NOT umask (the mask bits are cleared).

  • With a common umask of 022: files become 644, directories 755.

  • With 077: files become 600, directories 700 (private).

• Key nuance:

  • umask can only remove bits, never grant them, which is why files never get the execute bit by default.

  • Check with umask; set per-shell or in login profiles.

setuid and setgid are special permission bits that make an executable run with the owner's or group's identity rather than the caller's. They enable controlled privilege escalation, but a flaw in such a program is a serious vulnerability.

• setuid (set user ID): On execution the process gains the file owner's privileges (e.g. passwd is root-owned setuid so users can update /etc/shadow).

• setgid (set group ID):

  • On a binary: runs with the file's group.

  • On a directory: new files inherit the directory's group, which is useful for shared project folders.

• Security implications:

  • A setuid-root program with a bug (buffer overflow, unsafe PATH, command injection) can hand an attacker root.

  • Keep such binaries minimal, audited, and rare; prefer capabilities for narrow privileges.

  • The bit is ignored on scripts on Linux, and audit them with find / -perm -4000.

POSIX ACLs (Access Control Lists) extend the classic owner/group/other model by letting you grant permissions to multiple specific users and groups on a single file. getfacl reads them and setfacl sets them.

• Why they exist:

  • Traditional bits express only three identities (user, group, other), which is too coarse when several users need different access.

  • ACLs add named entries like user:alice:rw- or group:devs:r-x.

• Key concepts:

  • The mask entry sets the maximum effective permission for named users and groups.

  • Default ACLs on a directory are inherited by newly created files inside it.

  • A file with ACLs shows a + in ls -l output.

• The tools:

  • getfacl file lists all ACL entries including the mask.

  • setfacl -m u:alice:rw file modifies; setfacl -x u:alice file removes; -d sets defaults.

• Requires filesystem support (acl mount option, on by default in most modern setups).

The /etc/sudoers file defines who may run which commands as which users via sudo, and you edit it with visudo because it validates syntax before saving to prevent locking yourself out.

• Rule structure:

  • Format is who host = (as_whom) commands, e.g. alice ALL=(ALL:ALL) ALL.

  • Group rules use %: %wheel ALL=(ALL) ALL lets the wheel group do anything.

  • Can restrict to specific commands and add NOPASSWD: to skip the password prompt.

• Aliases and drop-ins:

  • Supports User_Alias, Cmnd_Alias, etc. for reuse.

  • Prefer separate files in /etc/sudoers.d/ for modular, package-friendly config.

• Why visudo:

  • It locks the file, opens an editor, and runs a syntax check on save.

  • A syntax error in sudoers can break sudo entirely, leaving no way to gain root; visudo refuses to save a broken file.

  • Use visudo -c to validate, or visudo -f /etc/sudoers.d/myfile for drop-ins.

Both are virtual (in-memory) filesystems that expose kernel data as files instead of storing anything on disk. /proc mainly surfaces per-process and system runtime info, while /sys (sysfs) presents a structured view of devices, drivers, and the kernel object hierarchy.

• /proc:

  • Per-process dirs /proc/<pid>/ hold status, fd/, cmdline, maps.

  • System-wide files: /proc/cpuinfo, /proc/meminfo, /proc/mounts.

  • Tunables under /proc/sys/ are writable (the backing for sysctl).

• /sys:

  • Hierarchical device model: /sys/class/net/eth0/, /sys/block/sda/.

  • Read and tweak hardware/driver attributes (e.g. LED brightness, scheduler).

• Example lookups:

  • Total RAM: cat /proc/meminfo.

  • An interface's MAC/state: cat /sys/class/net/eth0/address.

A journaling filesystem records intended changes in a dedicated log (the journal) before applying them to the main filesystem, so after a crash it can quickly replay or discard incomplete operations instead of scanning the whole disk. ext4 is a widely used example.

• The problem it solves:

  • A metadata update (e.g. adding a block to a file) touches several structures; a power loss mid-update leaves the filesystem inconsistent.

  • Without a journal, recovery means a slow full fsck.

• How the journal works:

  • Changes are first written to the journal and marked committed, then flushed to their final location (checkpointing).

  • On reboot the kernel replays committed but unapplied entries and discards incomplete ones, restoring consistency fast.

• ext4 journaling modes:

  • ordered (default): journals metadata, writes data before its metadata commits.

  • journal: logs both data and metadata (safest, slowest).

  • writeback: metadata only, no ordering guarantee (fastest, riskiest for stale data).

• Caveat: journaling protects consistency of structure, not necessarily every last byte of unsynced application data.

An inode (index node) is an on-disk data structure that stores all the metadata about a file plus pointers to the data blocks holding its contents. Notably, it does not store the filename: the name lives in the directory entry that maps a name to an inode number.

• What an inode stores:

  • File type (regular, directory, symlink, device) and permission bits (mode).

  • Owner UID and group GID.

  • Size in bytes and link count (number of hard links).

  • Timestamps: atime (access), mtime (content modified), ctime (inode changed).

  • Pointers to the actual data blocks on disk.

• What is NOT stored in the inode:

  • The filename: it is held in the directory, which maps names to inode numbers.

  • The file's actual data content (the inode only points to it).

• Consequence: one inode can have many names (hard links), all pointing to the same metadata and data.

An inode is the metadata structure describing a file (permissions, owner, timestamps, data-block pointers). The likely cause here is inode exhaustion: the filesystem still has free data blocks (50GB) but has run out of free inodes, so it cannot allocate metadata for even a tiny new file.

• Two separate limits:

  • Data blocks: raw space for file contents.

  • Inodes: a fixed pool allocated at mkfs time; each file/dir/symlink consumes one.

• Typical trigger: Millions of tiny files (mail queues, session/cache files) exhaust inodes long before space runs out.

• How to confirm and fix:

  • Run df -i to see inode usage (IUse% at 100%).

  • Delete unneeded small files, or recreate the filesystem with more inodes (mkfs -N / smaller bytes-per-inode).

Moving within the same filesystem keeps the same inode (it is just a rename/relink); moving across filesystems allocates a brand-new inode because it is really a copy-then-delete.

• Same filesystem move:

  • Only the directory entry changes: the name is unlinked from one directory and linked into another.

  • Inode number is unchanged, data blocks are not touched, so it is instant regardless of file size.

  • Uses the rename() syscall under the hood.

• Cross-filesystem move:

  • Inode numbers are only unique per filesystem, so the file must be physically copied to a new inode on the target, then the original unlinked.

  • New inode number, cost scales with file size, and it can partially fail (leaving a copy).

• Practical fallout: hard links break across filesystems (they cannot span devices), and interrupting a cross-fs move can leave a half-copied file.

A regular mount attaches a whole filesystem (a device) onto a mount point, whereas a bind mount makes an existing directory (or file) also appear at a second location in the same tree, without involving a separate device or filesystem.

• Regular mount:

  • Maps a block device/filesystem to a directory: mount /dev/sdb1 /mnt.

  • Introduces a new filesystem with its own inodes.

• Bind mount:

  • Remounts part of the existing tree elsewhere: mount --bind /src /dst.

  • Both paths share the same underlying inodes and data (a view, not a copy).

  • Stays on the same filesystem; no new device involved.

• Why use it:

  • Expose a subdirectory into a chroot/container, or present a path under a different location without symlinks.

  • Can be made read-only or private with a remount (mount -o remount,ro,bind).

An inode is the metadata structure identifying a file on a filesystem, referenced by a unique inode number. Renaming a file does not change its inode number, because the name is stored in the directory entry, not in the inode itself.

• Name vs inode:

  • A directory is a table mapping names to inode numbers.

  • The inode holds metadata and data pointers but not the name.

• What rename actually does:

  • It only updates the directory entry (or moves it between directories on the same filesystem) via rename().

  • The inode, its data blocks, and open file descriptors are untouched.

• Verify it: Check the number before and after with ls -i; it stays identical.

• Exception: renaming across a different filesystem is a copy+delete, which does produce a new inode.

The /proc directory is a virtual (pseudo) filesystem that the kernel generates in memory, exposing process and system information as files. Those files report 0 bytes because they have no real on-disk data: their contents are produced on demand by the kernel when you read them, so the size field is meaningless.

• What it contains:

  • Per-process directories named by PID (/proc/1234/status, cmdline, fd/).

  • System-wide info: /proc/cpuinfo, /proc/meminfo, /proc/mounts.

• Why size is 0:

  • Files are not backed by disk blocks; there is no stored length to report, so stat returns size 0.

  • The data is generated dynamically each time you open/read the file, reflecting current kernel state.

• Consequence: use cat or read the file to see live values; do not rely on ls -l sizes. Writing to some entries (under /proc/sys) tunes kernel parameters.

fsck (filesystem check) inspects and repairs inconsistencies in a filesystem's metadata, such as orphaned inodes, bad block references, or an incorrect free-space map, typically after an unclean shutdown.

• What it does:

  • It's a front-end that dispatches to a filesystem-specific checker (fsck.ext4, xfs_repair).

  • Verifies and fixes metadata consistency, moving unrecoverable fragments to lost+found.

• When it runs:

  • Automatically at boot when the filesystem is flagged dirty or the mount count/interval threshold is reached.

  • Manually by an admin on an unmounted filesystem for diagnosis or repair.

• Critical rule: only run it on an unmounted (or read-only) filesystem; checking a mounted, live filesystem can corrupt it.

• Journaling reduces need: journaled filesystems replay the journal for a fast recovery, so full fsck scans are rarer.

tmpfs is an in-memory filesystem: its contents live in RAM (and swap), so it's very fast but volatile, disappearing on unmount or reboot.

• Backed by memory, not disk:

  • Reads/writes hit RAM, giving very low latency; pages can spill to swap under memory pressure.

  • Grows dynamically up to a size limit rather than pre-allocating space.

• Volatile by design: Data is lost on reboot or unmount, so it suits caches and transient runtime data, not persistence.

• Common uses: Standard mounts like /run, /dev/shm, and often /tmp.

• Vs disk-backed: no durability guarantees and capacity competes with application RAM, but far faster than any disk filesystem.

A hard link is just another directory entry pointing to the same inode, and inode numbers are only unique within a single filesystem, so a link cannot reference an inode on another filesystem; directory hard links are forbidden to prevent loops and a broken tree structure.

• Can't cross filesystems:

  • A hard link stores an inode number, which is scoped to one filesystem; the same number means different files on different filesystems.

  • Use a symlink instead: it stores a path, so it can point anywhere, including across mounts.

• Can't link directories:

  • Multiple hard links to a directory could create cycles, trapping tools that walk the tree (find, rm -r).

  • It would also make parent (..) relationships ambiguous, breaking the strict tree the kernel assumes.

  • The kernel already creates the controlled directory hard links (. and ..); user-created ones are disallowed.

du measures space consumed by files/directories by summing their allocated blocks, while df reports usage from the filesystem's own accounting of a whole mounted device; they can disagree because they count different things.

• du (disk usage of files): Walks the tree and totals block allocation of the files it can see.

• df (disk free of a filesystem): Asks the filesystem superblock for total, used, and free space on the device.

• Why they disagree:

  • Deleted-but-open files: space is freed to df only when the last file handle closes, but du no longer sees them, so df reports more used.

  • Mount shadowing: files under a directory that has another filesystem mounted over it are counted by df but hidden from du.

  • Reserved blocks and filesystem metadata count against df but not du.

  • Sparse files and permissions du can't traverse also skew the sum.

• Tip: a filesystem full but low du often means a deleted file still held open by a process (lsof +L1).

LVM (Logical Volume Manager) is an abstraction layer between physical storage and filesystems that lets you pool disks and carve out flexible, resizable volumes without repartitioning; it stacks physical volumes into volume groups from which logical volumes are allocated.

• Physical Volume (PV): A disk or partition initialized for LVM with pvcreate; the raw capacity contribution.

• Volume Group (VG): A pool combining one or more PVs (vgcreate); capacity is divided into fixed-size extents (PEs).

• Logical Volume (LV): A virtual block device carved from a VG (lvcreate); you put a filesystem on it and mount it.

• Why it's useful:

  • Resize online: grow an LV and its filesystem, or add a new PV to expand the VG.

  • Snapshots, striping/mirroring, and spanning volumes across multiple disks.

• Relationship: PVs feed a VG, and LVs draw from the VG's extent pool (many-to-one at each layer).

Adding swap means formatting a device or file as swap with mkswap, then activating it with swapon so the kernel can use it as overflow for RAM.

1. Create the backing store: A dedicated partition, or a file via fallocate -l 2G /swapfile (set chmod 600 for security).

2. Format it as swap: mkswap /swapfile writes the swap signature and header.

3. Enable it: swapon /swapfile activates it immediately; swapon --show or free -h confirms.

4. Make it persistent: Add a line to /etc/fstab so it re-enables on boot.

Physical memory is the actual RAM installed in the machine; virtual memory is a per-process abstraction the kernel presents, mapping each process's private address space onto physical RAM (and disk) via page tables and the MMU.

• Physical memory: The finite, real hardware RAM, addressed by physical addresses.

• Virtual memory:

  • Each process sees its own large, contiguous address space, isolated from others.

  • The MMU translates virtual to physical addresses using page tables, page by page.

• Key benefits:

  • Isolation and protection: one process can't read another's memory.

  • Overcommit and paging: total virtual memory can exceed RAM; inactive pages spill to swap.

  • Demand paging: pages load only when touched, and shared/library pages map into many processes.

• Practical view: In tools like top, VIRT is the process's virtual size while RES is the resident physical RAM actually used.

VSZ is the total virtual address space a process has mapped (much of which may never be in RAM), while RSS is the portion of that actually resident in physical memory right now.

• VSZ (Virtual Memory Size):

  • Sum of all mappings: code, heap, stack, shared libraries, and reserved-but-unused regions.

  • Includes memory that is allocated but never touched, so it is often far larger than real usage.

• RSS (Resident Set Size):

  • Physical RAM currently backing the process (excludes what's been swapped out).

  • Counts shared pages (like libc) in every process sharing them, so summing RSS across processes double-counts.

• Practical takeaway:

  • RSS is closer to real memory pressure; VSZ mostly indicates address-space usage.

  • For a truer per-process footprint, look at PSS (proportional set size) in /proc/<pid>/smaps.

PID 1 is the first userspace process the kernel starts and the ancestor of every other process; besides launching and supervising the system, it adopts orphaned processes and reaps them so they don't linger as zombies.

• Role of PID 1:

  • Started directly by the kernel; it cannot be killed normally and its death panics the system.

  • On modern distros it's systemd, which brings up services, mounts, and targets, and manages shutdown.

• When a parent dies:

  • Its children become orphans and are re-parented to PID 1 (or a subreaper).

  • PID 1 calls wait() on them when they exit, collecting exit status so they don't become zombies.

• Why reaping matters: A zombie holds a PID-table entry until reaped; an init that doesn't reap (common bug in container PID 1) leaks zombies.

A unit is systemd's basic manageable object described by a configuration file: it represents something systemd can start, stop, or monitor. A service unit manages a process/daemon, while a target unit is just a grouping/synchronization point used to bring related units up together.

• Units in general:

  • Defined by files ending in a type suffix: .service, .socket, .mount, .timer, .target, etc.

  • Carry dependency and ordering directives like Wants=, Requires=, After=.

• Service unit (.service): Describes how to run a process: the ExecStart= command, restart policy, and process type (Type=simple, forking, etc.).

• Target unit (.target):

  • Has no process of its own; it groups units so reaching the target means its dependencies are active.

  • Replaces SysV runlevels (e.g. multi-user.target, graphical.target).

systemd is the modern init system and service manager (PID 1) for most Linux distributions; it replaces SysVinit's sequential, script-driven runlevels with a dependency-based model that starts services in parallel and supervises them for their lifetime.

• Parallel vs sequential startup: SysVinit runs numbered shell scripts in /etc/rc.d one after another; systemd resolves a dependency graph and starts independent units in parallel, booting faster.

• Declarative units vs shell scripts: systemd uses declarative unit files; SysV uses hand-written scripts that must reimplement start/stop/status logic.

• Targets vs runlevels: Named targets (multi-user.target) replace numeric runlevels (0-6) and can be combined more flexibly.

• Supervision and features:

  • systemd tracks processes with cgroups, so it can reliably restart crashed services and cleanly kill all children.

  • Adds socket/timer activation, unified logging via journald, and one control tool (systemctl).

• Criticism: Seen as monolithic and doing too much beyond init, which contrasts with the traditional Unix simplicity of SysV.

GRUB is the bootloader that loads and hands control to the kernel, while the initramfs is a temporary in-memory root filesystem that gives the kernel the drivers and tools it needs to reach and mount the real root filesystem.

• GRUB (GRand Unified Bootloader):

  • Runs after firmware (BIOS/UEFI), presents a boot menu, and lets you pass kernel parameters.

  • Loads the kernel image (vmlinuz) and the initramfs into memory, then transfers control to the kernel.

• initramfs / initrd:

  • A small cpio archive unpacked into RAM that acts as an early root filesystem.

  • Contains kernel modules and tools needed to mount the real root: disk/RAID/LVM drivers, encryption (cryptsetup), filesystem support.

  • Solves a chicken-and-egg problem: the kernel may need a driver that lives on a disk it cannot yet read.

• Handoff to the real system: Once the true root is mounted, control switches to it (pivot_root) and /sbin/init (typically systemd) starts as PID 1.

• initrd vs initramfs: initrd is the older ramdisk (a block device image); initramfs is the modern cpio archive, though the names are often used interchangeably.

systemd targets are named groups of units that describe a desired system state, replacing the fixed, numbered SysV runlevels with a more flexible, dependency-driven model.

• SysV runlevels:

  • A fixed set of numbered states (0-6) started sequentially by scripts in /etc/rc.d/.

  • Startup is serial and ordered by symlink naming (S01, S02), which is slow.

• systemd targets:

  • Named units (.target) that group and pull in other units via dependencies, started in parallel.

  • Can represent more than a whole-system state (e.g. network.target as a synchronization point).

• Rough mapping:

  • runlevel 3 → multi-user.target (multi-user, no GUI).

  • runlevel 5 → graphical.target.

  • runlevel 0/6 → poweroff.target / reboot.target.

• Set the default with systemctl set-default and switch live with systemctl isolate.

journald is systemd's logging service that collects log data into a structured, indexed binary journal, whereas traditional syslog writes plain-text lines to files. They often coexist, with journald feeding a syslog daemon.

• Structured, indexed storage: Stores key-value metadata per entry (unit, PID, UID, boot ID), so you can filter precisely with journalctl -u ssh or --since.

• Central collection: Captures stdout/stderr of services, kernel messages, and syslog-style messages in one place.

• Binary vs plain text: The journal is a binary format read via journalctl; syslog produces greppable text in /var/log.

• Persistence and rotation: Can be volatile (/run/log/journal) or persistent (/var/log/journal); it self-manages size limits.

• They complement each other: journald can forward to rsyslog for long-term text archives or remote log servers.

Use journalctl filtered to the failing unit and time window to read its logs, combining it with systemctl status to see the exit code and the most recent lines.

• Start with status: systemctl status myapp shows active state, the exit/return code, and a short log tail.

• Read the unit's full log: journalctl -u myapp shows only that unit; add -e to jump to the end.

• Narrow by time and boot: journalctl -u myapp --since "10 min ago" or -b for the current boot / -b -1 for the previous one.

• Increase detail: -p err filters by priority; -o verbose shows all structured fields; -f follows live while you retry the start.

• Common findings: missing dependency, bad config file path, permission denied, or a port already in use in the traceback.

logrotate is a utility that periodically rotates, compresses, and deletes old log files so they don't grow without bound, which is essential to keep long-running servers from filling their disks.

• What it does:

  • Renames the current log (e.g. app.log → app.log.1), starts a fresh one, and prunes files past the retention count.

  • Optionally compresses rotated files (gzip) to save space.

• How it's triggered:

  • Usually run daily via cron or a systemd timer; rotation can be by size, time, or both.

  • Config lives in /etc/logrotate.conf and per-app files in /etc/logrotate.d/.

• Handling open files: copytruncate copies then truncates in place (for apps that keep the file open), while postrotate scripts can signal the app to reopen its log.

• Why it matters: without rotation a busy log can exhaust the disk, crashing services and making the box hard to recover.

All three schedule work, but differ in recurrence and features: cron runs recurring jobs, at runs a one-time job at a future moment, and systemd timers are the modern, dependency-aware replacement with richer control.

• cron:

  • Recurring, calendar-based jobs; simple and ubiquitous.

  • Misses runs if the machine is off at the scheduled time (unless using anacron).

• at:

  • Fire-once scheduling: echo "cmd" | at now + 1 hour.

  • Good for deferred one-off tasks, not recurrence.

• systemd timers:

  • A .timer unit triggers a .service unit; supports OnCalendar= and monotonic timers.

  • Advantages: logging via journalctl, Persistent=true catches missed runs, dependency ordering, resource limits.

• Rule of thumb: recurring simple job use cron; one-shot use at; robust, logged, dependency-aware use systemd timers.

Every resource limit has two values: the soft limit is the actual enforced ceiling a process operates under, and the hard limit is the maximum the soft limit may be raised to. For open files/sockets this governs how many file descriptors a process can hold.

• Soft limit:

  • The value actually enforced; exceeding it gives EMFILE / "Too many open files".

  • An unprivileged process can raise its own soft limit up to the hard limit.

• Hard limit: The upper bound for the soft limit; only root can raise it above its current value.

• Checking and setting:

  • ulimit -Sn shows the soft, ulimit -Hn the hard limit for open files.

  • Persist across sessions via /etc/security/limits.conf or a systemd unit's LimitNOFILE=.

• Sockets count as file descriptors, so a busy server hitting the soft nofile limit fails to accept new connections.

These three tools each target a different subsystem: vmstat gives a whole-system CPU/memory/IO overview, iostat focuses on per-device disk activity, and free reports memory usage. Together they help locate the bottleneck.

• vmstat:

  • Columns for processes (r = run queue, b = blocked), memory, swap si/so, IO, and CPU (us/sy/id/wa).

  • High wa (IO wait) or high r points to IO or CPU saturation; nonzero si/so means swapping.

• iostat:

  • Per-disk throughput and, with -x, %util and await (average IO latency).

  • High %util with rising await indicates a disk bottleneck.

• free:

  • Shows total/used/free memory plus buffers/cache and swap.

  • Focus on the available column: cache is reclaimable, so low free alone is not a problem.

• Run them with an interval (e.g. vmstat 1) to see trends, not a single frozen snapshot.

lsof ("list open files") reports which files are open and which processes hold them. Since Linux treats nearly everything (regular files, sockets, pipes, devices) as a file, it's a broad diagnostic tool.

• Problems it helps diagnose:

  • "Device busy" on unmount: lsof /mnt/x finds the process holding a file on that filesystem.

  • Deleted-but-open files eating disk space: lsof | grep deleted shows space held by a still-running process.

  • Which process owns a port: lsof -i :8080.

  • File descriptor leaks: lsof -p PID counts how many descriptors a process holds.

• Useful flags: -i for network connections, -u user by user, -p PID by process, +D dir for a directory tree.

• Related to ss/netstat for sockets, but lsof ties the open resource back to the owning process.

/etc/hosts is a static local table mapping hostnames to IP addresses, while /etc/resolv.conf tells the resolver which DNS servers to query. By default /etc/hosts is checked before DNS, and that ordering is configured in /etc/nsswitch.conf.

• /etc/hosts: Manual entries like 127.0.0.1 localhost; no network lookup needed, great for overrides and testing.

• /etc/resolv.conf:

  • Lists nameserver IPs and search domains used when a name isn't in hosts.

  • Often auto-managed by systemd-resolved or NetworkManager.

• The order is set in /etc/nsswitch.conf:

  • The hosts: line, typically hosts: files dns, means try files (/etc/hosts) first, then dns.

  • Reordering it (e.g. dns files) flips the precedence.

ping tests whether a host is reachable and measures round-trip time, while traceroute reveals each router (hop) along the path to that host by cleverly manipulating the TTL field.

• ping:

  • Sends ICMP echo requests and waits for echo replies: a single reachability + latency check.

  • Tells you if a host is up and how fast, but nothing about the path.

• traceroute: Discovers the ordered list of routers between you and the destination.

• How TTL maps the path:

  1. Each IP packet has a Time To Live counter; every router decrements it by 1.

  2. When TTL reaches 0, that router drops the packet and returns an ICMP Time Exceeded message, revealing its address.

  3. traceroute sends probes with TTL=1, then TTL=2, and so on, so each successive hop identifies itself in turn.

  4. It stops when the destination itself replies (or a max hop count is hit).

The loopback interface (lo, address 127.0.0.1) lets a machine talk to itself over the network stack without any physical hardware. Many services depend on it, so disabling it breaks a surprising amount of software.

• Purpose:

  • Provides a virtual interface for local inter-process communication over TCP/IP.

  • Lets a client and server on the same host communicate via localhost without touching a NIC or the external network.

• Common dependents: Databases (PostgreSQL, MySQL) bound to 127.0.0.1, local web servers, DNS resolvers, X11.

• Can it function without lo?:

  • Technically the kernel boots, but any app that connects to 127.0.0.1 fails, so in practice the system is badly broken.

  • Loopback is effectively mandatory for a correctly functioning Linux system.

Both display network connections and sockets, but ss is the modern replacement: it is faster and gives more detail because it reads socket data directly from the kernel, whereas netstat is a legacy tool that parses /proc.

• netstat:

  • Part of the older net-tools package, now deprecated on many distros.

  • Reads /proc/net/* files, which is slower on hosts with many connections.

• ss:

  • Part of iproute2; uses netlink to query the kernel directly.

  • Faster, scales better, and exposes richer info like TCP internal state (congestion window, timers) via ss -i.

• Flags largely overlap: Common options like -l, -t, -u, -n, -p mean the same in both, easing the transition.

An SSH tunnel wraps arbitrary TCP traffic inside an encrypted SSH connection, forwarding a port on one machine to a host:port reachable from the other end. This secures otherwise plaintext traffic and lets you reach services across network boundaries.

• Local forwarding (-L):

  • Opens a port on your local machine that tunnels to a destination reachable from the SSH server.

  • Example: ssh -L 5432:db.internal:5432 user@gateway lets you connect to localhost:5432 as if you were on the remote DB.

• Remote forwarding (-R): Opens a port on the SSH server that tunnels back to a host reachable from your client: useful to expose a local service outward.

• Dynamic forwarding (-D): Turns SSH into a local SOCKS proxy so applications route many destinations through the tunnel.

• Mechanics:

  • SSH listens on the forwarded port, encrypts data over the existing session, and the far end relays it to the real target.

  • Only the SSH hop is encrypted; the final segment from server to target is plain TCP.

rsync is a file-synchronization and transfer tool that copies only the differences between source and destination, making it far more efficient than scp for repeated transfers or large trees.

• Delta transfer algorithm: Compares files and sends only changed blocks, not the whole file, saving bandwidth on updates.

• Resumable and incremental: Interrupted transfers can resume; re-running only syncs what changed, whereas scp recopies everything.

• Preserves metadata: With -a (archive) it keeps permissions, timestamps, symlinks, and ownership.

• Flexible options: Can delete extraneous files (--delete), compress in transit (-z), and run over SSH for encryption.

• When scp is fine: A one-off copy of a single small file; the delta logic gives no benefit there.

The ip command (from iproute2) is the modern, unified tool for network configuration, replacing the deprecated ifconfig, route, and arp utilities from net-tools.

• One tool vs many:

  • ip handles addresses, links, routes, and neighbors via subcommands: ip addr, ip link, ip route, ip neigh.

  • Old workflow needed ifconfig for interfaces, route for routing, arp for the ARP table.

• Feature completeness:

  • ip exposes modern kernel features ifconfig cannot show, like multiple addresses per interface, policy routing, and namespaces.

  • It talks to the kernel over netlink, which is more capable than the older ioctl interface.

• Status: net-tools is unmaintained and often not installed by default on newer distros; ip is the expected standard.

All three query DNS, but they differ in detail and precision: dig is the scriptable low-level tool of choice, host gives quick concise answers, and nslookup is the older interactive tool still common for quick checks.

• dig (Domain Information Groper):

  • Verbose, structured output showing the exact query, answer, authority, and additional sections plus TTLs.

  • Query a specific server and record type: dig @8.8.8.8 example.com MX; use +short for scripting and +trace to follow delegation from the root.

• host: Simple one-line answers, good for a fast forward or reverse lookup: host example.com or host 8.8.8.8.

• nslookup: Older, has an interactive mode; handy on mixed platforms but less precise output than dig.

• Troubleshooting value:

  • They bypass /etc/hosts and nsswitch.conf, talking straight to a resolver, so they isolate whether a failure is DNS itself versus local name-service config.

  • Comparing answers from different servers (@resolver) exposes stale caches or split-horizon issues.

netcat (nc) is the "TCP/UDP Swiss Army knife": it reads from and writes to network connections, letting you open, listen on, or test raw sockets for debugging connectivity and data flow.

• Port and connectivity testing: Check if a port is open: nc -zv host 443 (-z scans without sending data, -v is verbose).

• Ad-hoc client/server: Listen on a port with nc -l 9000 and connect from another host to verify a firewall path end to end.

• Data transfer and piping: Pipe files or command output across a socket; useful for quick transfers or feeding a service raw input.

• Protocol debugging: Type raw HTTP/SMTP by hand to see exactly what a server returns.

• Caveat: Variants differ (traditional vs ncat/OpenBSD nc); flags like -e are often disabled for security since it can spawn shells.

Both make SSH key-based logins convenient and manageable: ssh-agent caches your decrypted private keys in memory so you type a passphrase once, while ~/.ssh/config stores per-host connection settings so you don't repeat long command-line options.

• ssh-agent holds keys in memory:

  • You unlock a passphrase-protected key once with ssh-add; the agent then answers auth challenges without re-prompting.

  • Enables agent forwarding (ssh -A) so a remote host can use your local keys to hop further, without copying the key there.

• ~/.ssh/config defines per-host aliases and options:

  • Set HostName, User, Port, IdentityFile, ProxyJump etc. per host or wildcard.

  • Turns a long command into a short alias: ssh prod.

• Together: config decides which key/host, agent supplies the credential securely.

Both solve the same problem (install packages, resolve dependencies, track what's on the system) but use different tools and formats: Debian uses .deb with dpkg/apt, while RHEL uses .rpm with rpm/dnf.

• Package formats differ:

  • Debian family: .deb archives.

  • RHEL family: .rpm archives.

• Low-level tools (single package, no dependency resolution):

  • Debian: dpkg.

  • RHEL: rpm.

• High-level tools (repositories + dependency resolution):

  • Debian: apt (apt-get), metadata via /etc/apt/sources.list.

  • RHEL: dnf (successor to yum), repos in /etc/yum.repos.d/.

• Practical differences: Package naming, split of -dev vs -devel packages, and update cadence vary between families.

Building from source means turning source code into an installed binary in three stages: detect the environment, compile, then copy the results into place. The classic chain ./configure && make && make install runs those stages in order.

• ./configure: adapt to the system:

  • A script (usually Autotools-generated) that probes for compilers, libraries, and headers, then writes a Makefile.

  • Common flag: --prefix=/usr/local sets the install location; fails early if a dependency is missing.

• make: compile: Reads the Makefile and compiles sources into binaries/libraries, rebuilding only what changed.

• make install: place files: Copies binaries, libraries, and man pages under the prefix; usually needs sudo if installing into system paths.

• Caveats:

  • The package manager doesn't track these files: uninstalling means make uninstall or a tool like checkinstall.

  • Some projects use CMake or Meson instead of Autotools, but the compile-then-install idea is the same.