Top 60 Linux Interview Questions (2026)

Linux is the kernel: the core program that manages hardware, memory, processes, and the file system. A distribution is the kernel plus everything you actually use, GNU tools, a shell, a package manager, and default software, bundled and maintained together.

So Ubuntu, Debian, and Fedora all run the same Linux kernel but differ in package managers, release cadence, and defaults. When someone says they run Linux, they mean a distribution built on the kernel.

Everything hangs off a single root, written /. There are no drive letters like on Windows; disks and partitions mount into the tree at chosen points. Each top-level directory has a defined job, set by a shared standard, so any Linux system is navigable the same way once you know the map.

Knowing the map means you find config in /etc, logs in /var/log, and user files in /home without guessing.

An absolute path starts from root and always begins with /, like /home/asha/report.txt. It means the same thing no matter where you are. A relative path starts from your current directory, like ../logs/app.log, so its meaning depends on where you run it.

The shortcuts matter too: . is the current directory, .. is the parent, ~ is your home directory.

ls lists directory contents. On its own it shows names; the flags are where the real work happens. -l gives the long format with permissions, owner, size, and time; -a shows hidden dotfiles; -h makes sizes human-readable; -t sorts by modification time.

Combining them is normal: ls -lah is one of the most typed commands on any Linux box.

Every file carries three permission sets: one for the owner, one for the group, and one for everyone else. Each set has three bits: read (r), write (w), and execute (x). ls -l prints them as a 10-character string like -rwxr-xr--, where the leading character is the file type and the next nine are those three sets in order.

Read lets you view a file or list a directory; write lets you change a file or add entries to a directory; execute lets you run a file or enter a directory. On directories, x is what lets you cd in.

chmod sets permissions. In numeric mode, each of the three sets (owner, group, others) becomes a single digit built by adding read=4, write=2, and execute=1. So 7 is rwx, 5 is r-x, 4 is r--, and 6 is rw-. You read the three digits left to right as owner, group, others, which is why one number describes the whole file.

chmod 644 is the normal permission for a regular file (owner reads and writes, everyone else reads). chmod 755 is normal for scripts and directories (owner does everything, others read and execute).

chown changes a file's owner and, with the owner:group form, its group too; chgrp changes only the group. Ownership decides which of the three permission sets applies to you, so a 'permission denied' error is often an ownership problem, not a mode-bits problem. Fixing the owner can matter more than fixing the rwx flags.

You usually need root (sudo) to give a file to another user.

cat dumps the whole file to the screen, fine for short files and for concatenating. less pages through a large file without loading it all, with search and scrolling. head shows the first lines, tail the last, and tail -f follows a file as it grows, which is how you watch a log live.

grep searches text for lines matching a pattern and prints the ones that match. It's the workhorse for finding a string inside files, or for filtering the output of another command through a pipe. You give it a pattern and one or more files, or you feed it a stream, and it keeps only the lines you asked for.

The flags that matter: -i ignores case, -r recurses through directories, -n shows line numbers, -v inverts the match, and -E enables extended regular expressions.

A pipe (|) sends one command's standard output into the next command's standard input, so you chain small tools into a bigger job. Redirection sends output to or from files instead: > writes (overwriting), >> appends, and < reads input from a file.

Every process starts with three streams: stdin (0), stdout (1), and stderr (2). Understanding those numbers is what lets you route errors separately from normal output.

ps shows a snapshot of processes; ps aux is the common form listing every process with its user, CPU, memory, and command. top and htop give a live, sorted view that updates. Each process has a PID, and that PID is what you use to inspect or stop it.

kill sends a signal to a process by PID. Plain kill sends SIGTERM (15), which politely asks the process to clean up and exit; a well-behaved program flushes buffers and closes files first. kill -9 sends SIGKILL, which the kernel enforces immediately and the process can't catch or ignore.

Reach for SIGTERM first. Use SIGKILL only when a process is stuck and ignoring the polite request, because it gives the program no chance to shut down cleanly.

find walks a directory tree and matches on criteria: name, type, size, modification time, permissions, owner. It can also run an action on each match with -exec or -delete, which makes it a tool for bulk operations, not just search.

cp copies files, mv moves or renames them, and rm removes them. Directories need the -r (recursive) flag for cp and rm because they operate on files by default. The flag that saves careers is -i (interactive), which prompts you before overwriting or deleting, giving you a chance to catch a wrong path.

rm -rf is fast and unforgiving: it deletes recursively and forcefully with no prompt and no trash. Say out loud that you double-check the path before running it.

man opens the manual page for a command, with its options and usage. --help gives a shorter summary printed by the command itself. For a one-line description of what a command is, use whatis, and to find commands by keyword use apropos.

Knowing where the answer lives beats memorizing every flag. Interviewers like candidates who say 'I'd check the man page' instead of guessing.

root is the superuser (UID 0) with unrestricted access to every file and command. sudo runs a single command with raised privileges, checked against a policy in /etc/sudoers, so admins get root access for one command without logging in as root.

The practice reason: sudo logs who ran what, and limits blast radius. Running as root all day is how a typo wipes a system.

Environment variables are named values that the shell and the programs it launches read for configuration. PATH lists the directories searched for commands, HOME points to your home directory, and applications read their own, like DATABASE_URL. You print one with echo $VAR and list them all with env, and every child process inherits the exported ones.

Set for one command inline, export for the current shell and its children, or add to a shell startup file like ~/.bashrc to make it persistent.

Through a package manager, which resolves dependencies and installs from trusted repositories rather than by downloading random binaries. Debian and Ubuntu use apt with .deb packages; Fedora and Red Hat use dnf with .rpm packages; Arch uses pacman. Each one fetches, verifies, and installs the software plus anything it needs to run.

The pattern is the same everywhere: update the package index, then install, remove, or upgrade. Knowing your target distro's manager is table stakes for a Linux role.

A hard link is another directory entry pointing to the same inode (the same actual data on disk). Delete one name and the data survives as long as any hard link remains. A symbolic link (symlink) is a small file that stores a path to another file; delete the target and the symlink dangles.

Practical differences: hard links can't cross file systems or point to directories; symlinks can do both but break if the target moves.

Globbing lets the shell expand a pattern into a list of matching filenames before a command even runs. The star * matches any run of characters, ? matches exactly one character, [abc] matches one character from a set, and {a,b} expands into each option in turn. The command receives the expanded filenames, not the pattern.

The shell does the expansion, not the command, so 'ls *.txt' hands ls the actual list of matches. That's why an unmatched pattern sometimes passes through literally.

df reports free and used space for each mounted file system, and df -h makes those numbers human-readable in gigabytes. du reports how much space specific files and directories consume, and du -sh gives a single summarized, human-readable total for a path. df answers 'is the disk full', du answers 'what filled it'.

The pairing matters in practice: df tells you a disk is full, and du -sh sorted helps you find what's eating it.

A shebang is the first line of a script, like #!/bin/bash, telling the kernel which interpreter should run the file. Make the file executable with chmod +x, then run it by path, like ./hello.sh. The kernel reads the shebang and launches that interpreter with your script as its argument.

Without the executable bit you can still run it by passing it to an interpreter, like 'bash script.sh', which ignores the executable bit but still respects the interpreter you name.

The shell keeps a history of what you've typed. history lists it with line numbers, the up arrow steps back through it, and !! reruns the last command. Ctrl+R starts a reverse search: type a few characters and it finds the most recent matching command, which is faster than scrolling.

Handy expansions: !$ is the last argument of the previous command, and !abc reruns the most recent command starting with abc. sudo !! reruns the last command with sudo, the fix for 'permission denied'.

An alias is a shorthand for a longer command: alias ll='ls -lah' means typing ll runs the long form. Defined at the prompt, an alias lasts only for that session. To keep it, put it in a shell startup file that runs when a new shell opens, like ~/.bashrc for Bash or ~/.zshrc for Zsh.

That's why 'my alias disappeared after I closed the terminal' is a startup-file question. Login shells and interactive shells read different files, which explains why an alias sometimes works in one place and not another.

An inode is the data structure that stores a file's metadata: permissions, owner, group, size, timestamps, link count, and pointers to the data blocks on disk. The one thing it does not store is the filename; names live in directory entries that map to inode numbers.

That split explains hard links (many names, one inode) and why a file system can run out of inodes while showing free space: you've hit the limit on files, not bytes.

The main states are running or runnable (R), interruptible sleep (S, waiting on an event and wakeable by a signal), uninterruptible sleep (D, usually blocked on I/O and ignoring signals until it returns), stopped (T), and zombie (Z, finished but not yet reaped). ps and top show a state column with these single-letter codes.

The two that matter in interviews are D and Z. A process stuck in D is waiting on I/O and can't even be killed with SIGKILL until the I/O returns; a zombie has finished but its parent hasn't reaped its exit status yet.

A zombie has exited but its parent hasn't called wait() to collect the exit status, so the kernel keeps a tiny entry alive. Zombies use no CPU or memory beyond that entry; a pile of them means a parent isn't reaping children. An orphan is a still-running process whose parent died.

The kernel handles orphans automatically: init (PID 1) adopts them and reaps them when they exit. Zombies clear when the parent finally reaps them or when the parent dies and init takes over.

systemd is the init system and service manager on most modern distributions. It runs as PID 1, brings the system up at boot, and then starts, stops, and supervises services that are defined as unit files. systemctl is the command you drive it with, and journalctl reads the logs it collects. If a service dies, systemd can restart it automatically.

The everyday verbs: start, stop, restart, status, and enable (start at boot) versus disable. A unit's status shows whether it's active, its recent log lines, and its main PID.

cron runs commands on a schedule defined by five time fields: minute, hour, day of month, month, and day of week, followed by the command. crontab -e edits your user's schedule; crontab -l lists it. System-wide jobs live in /etc/crontab and /etc/cron.d.

The classic mistakes: cron runs with a minimal environment (so use absolute paths), and it doesn't load your shell profile, so PATH surprises are common.

sed is a stream editor for line-based transformations: find and replace, delete lines, insert text, all in a pipeline without opening an editor. awk is a small language for column-oriented text: it splits each line into fields and lets you filter, compute, and format, which makes it the go-to for parsing logs and tabular output.

Rule of thumb: reach for sed when you're editing text and awk when you're extracting or summarizing columns.

You generate a key pair: a private key that stays on your machine and a public key you copy to the server's ~/.ssh/authorized_keys. When you connect, the server challenges you and your client proves it holds the matching private key, so no password crosses the wire.

It's more secure and scriptable than passwords: protect the private key with a passphrase, use ssh-agent so you type that passphrase once, and disable password login on servers once keys work.

ip has replaced the old ifconfig for addresses and routes: ip addr shows interfaces, ip route shows the routing table. ss (the modern netstat) lists sockets and listening ports. ping tests reachability, and curl checks whether an HTTP service actually responds.

For 'why can't I reach this service', the sequence is usually: is the interface up (ip addr), is there a route (ip route), is the port listening (ss -tlnp), and does the firewall allow it.

ss -tlnp lists TCP listening sockets with the owning process; add a filter for the port. lsof -i :PORT does the same from the file-descriptor angle. This is the first move when a service says 'address already in use' or a port refuses connections.

Chain small tools: extract the field you care about, sort it, collapse duplicates with a count, then sort by that count. The classic 'top N' recipe is cut or awk to pick the column, then sort, uniq -c, and sort -rn.

This composition is the heart of the Unix philosophy, and interviewers love it because it shows you think in pipes rather than reaching for a script.

xargs takes items from standard input and turns them into arguments for another command. You need it when a command takes arguments rather than stdin, like rm or chmod, and you're feeding it a list produced by find or grep.

The safe pairing is find -print0 with xargs -0, which uses null separators so filenames with spaces or newlines don't break the command.

Append & to run a command in the background; jobs lists background jobs of the current shell; fg brings one to the foreground and bg resumes a stopped one. Ctrl+Z suspends the foreground job so you can push it to the background with bg.

The catch: background jobs die when the shell closes because they receive SIGHUP. Use nohup or, better, a terminal multiplexer like tmux or a systemd service for anything that must outlive the session.

useradd (or the friendlier adduser on Debian) creates accounts; usermod changes them; userdel removes them. Groups are how you grant shared access: create with groupadd, add a user with usermod -aG. Account data lives in /etc/passwd, groups in /etc/group, and password hashes in /etc/shadow.

The flag that catches people is -a in usermod -aG: without -a you replace the user's supplementary groups instead of appending, which quietly removes their other memberships.

Linux has one directory tree, so a disk or partition becomes usable by mounting it onto a directory (a mount point). mount attaches it now; entries in /etc/fstab make mounts persist across reboots. umount detaches, and lsblk or df show what's mounted where.

The reboot-safe answer is /etc/fstab plus a mount option like defaults. A bad fstab entry can block boot, so people test with 'mount -a' before rebooting.

ulimits are per-process resource caps that the kernel enforces: the maximum number of open file descriptors, the process count, memory, core dump size, and more. ulimit -n shows the open-files limit for the current shell, which is a frequent culprit when a busy server starts logging 'too many open files' under load. Raising it is often the fix.

There are soft limits (the current cap, raisable up to the hard limit) and hard limits (the ceiling, only root raises). Persistent changes go in /etc/security/limits.conf or a systemd unit's LimitNOFILE.

tar bundles many files into one archive; on its own it doesn't compress, but it delegates to gzip, bzip2, or xz through a flag. tar -czf creates a gzip-compressed archive, tar -xzf extracts one, and tar -tzf lists the contents without extracting anything. So tar handles the grouping and the chosen tool handles the squeezing.

The letters are worth memorizing: c create, x extract, t list, z gzip, f file, v verbose. gzip alone compresses a single file; tar is what groups a directory first.

which shows the path of the executable the shell would run for a given name. type is more informative: it tells you whether the name is a binary, a shell builtin, an alias, or a function, which matters because an alias can shadow a real command.

command -v is the portable, scriptable version. Reaching for type when 'the command does something weird' is how you catch a sneaky alias in a dotfile.

logrotate rotates, compresses, and deletes old logs on a schedule defined in /etc/logrotate.conf and /etc/logrotate.d. A config sets how often to rotate, how many old copies to keep, and whether to compress, so a chatty service can't quietly fill the disk.

For systemd services logging to the journal, journald has its own size and retention limits (SystemMaxUse). Naming both paths shows you know where logs actually live on a modern box.

Every command returns an exit status: 0 means success, any non-zero value means failure. The shell stores the last one in $?. Scripts read it to branch, and && / || chain commands on success or failure without an explicit if.

Conventions worth knowing: 1 is a general error, 2 is misuse, and 126/127 mean not executable or not found. In a script, 'set -e' makes it stop on the first failing command.

Load average is the number of processes running or waiting to run, averaged over 1, 5, and 15 minutes, shown by uptime and top. On Linux it counts processes in uninterruptible sleep (D, usually disk I/O) too, so high load doesn't always mean CPU-bound.

Read it against core count: a load of 4 on a 4-core box is fully busy but not backed up; the same load on a single core means work is queueing. Compare the three windows to see whether load is rising or clearing.

Firmware (BIOS or UEFI) runs its power-on checks and hands off to a bootloader, usually GRUB, which loads the kernel and an initramfs into memory. The kernel initializes hardware, mounts the root file system, then starts PID 1 (systemd on most distros).

systemd brings the system to its target (multi-user or graphical) by starting units in dependency order, mounting file systems, and launching services. Naming each handoff, firmware to bootloader to kernel to init to services, is what senior the key signal is.

Each process sees its own virtual address space; the kernel maps virtual pages to physical RAM on demand and tracks them in page tables. When RAM is tight, the kernel evicts less-used pages to swap space on disk, freeing RAM for active work. Swap is a safety valve, not extra fast memory: touching swapped-out pages is orders of magnitude slower.

The vm.swappiness knob tunes how readily the kernel swaps. The failure mode to name is thrashing: when the working set exceeds RAM, the system spends its time swapping pages in and out and throughput collapses.

When the system runs out of memory and can't reclaim enough, the kernel's out-of-memory killer picks a process to kill to keep the machine alive. It scores candidates by a badness heuristic (roughly memory footprint adjusted by oom_score_adj) and kills the highest score. You find its work in the kernel log, not the app's log.

The fixes depend on cause: cap a leaking service with cgroup memory limits, add swap as a buffer, tune oom_score_adj to protect critical processes, or right-size the box. The tell that a process was OOM-killed is a dmesg line, not a normal crash.

strace traces the system calls a process makes and the signals it receives, so you see exactly where it talks to the kernel: which files it opens, which fail, which network calls hang. When a program dies silently or hangs, strace shows the last syscall it was waiting on.

The common moves: strace -f follows child processes, -e trace=file or =network filters to the calls you care about, and -p attaches to a running PID. It slows the target, so use it surgically.

Namespaces isolate what a process can see: separate PID trees, network stacks, mount tables, users, and hostnames, so a process thinks it has its own system. cgroups (control groups) limit and account for what a process can use: CPU, memory, I/O, and process count.

Together they are the kernel foundation of containers. Docker and Kubernetes don't invent isolation; they orchestrate namespaces for the 'separate view' and cgroups for the 'capped resources'. Saying that split is the answer to 'how do containers actually work?'.

A signal is an asynchronous notification the kernel delivers to a process. Most can be caught and handled; two cannot: SIGKILL (9) and SIGSTOP force termination and suspension with no handler. Handlers let a program shut down gracefully, reload config, or reopen log files.

The production set: SIGTERM (polite shutdown, the default kill and what orchestrators send), SIGHUP (traditionally 'reload your config'), SIGKILL (last-resort force), and SIGINT (Ctrl+C). Graceful shutdown means catching SIGTERM to drain connections before exiting.

Confirm and locate first: top or htop to see whether one process or many, and whether it's user CPU, system CPU, or I/O wait. If it's one process, drill in with per-thread view (top -H) or a profiler like perf top to find the hot function. If it's I/O wait masquerading as load, iostat and iotop point at the disk.

Then correlate with recent deploys and traffic, form a hypothesis (a hot loop, a retry storm, GC pressure, a runaway query), and verify with a measurement before you change anything. The structure, observe then narrow then verify, is what the question scores.

The usual cause is a deleted file that a process still holds open. The directory entry is gone so du can't see it, but the inode and its blocks stay allocated until the last file descriptor closes. A rotated log file that the app still writes to is the classic culprit.

Find it with lsof | grep deleted, then either restart the holding process or truncate the file through its /proc file descriptor. The other suspect is inode exhaustion, which df -i confirms.

The kernel's netfilter framework hooks packets at points in their journey, and a firewall tool writes rules into it. iptables organizes rules into tables (filter, nat, mangle) and chains (INPUT, OUTPUT, FORWARD); each packet walks the relevant chain and the first matching rule decides accept, drop, or reject. nftables is the modern replacement with one unified tool and better performance.

In practice many teams use a front end (ufw or firewalld) that generates the low-level rules. Knowing the chain model underneath, and that nftables is where new work goes, is the level this question checks.

Static linking copies library code into the executable at build time, so it runs with no external dependencies but is larger and can't pick up a library security fix without rebuilding. Dynamic linking leaves the executable referencing shared libraries (.so files) that load at runtime, so binaries are smaller and share one copy of a library, patched in one place.

The trade-off is portability versus size and updatability. ldd shows a binary's shared-library dependencies; a missing .so is the classic 'error while loading shared libraries' failure.

Both are virtual file systems backed by the kernel, not disk. /proc exposes per-process and system information as files: /proc/PID/ has a process's memory maps, open files, and status; /proc/meminfo and /proc/cpuinfo report system state. /sys exposes device and kernel object information and lets you tune some kernel parameters by writing to files.

This is why so many Linux tools are just formatted reads of /proc, and why 'everything is a file' is more than a slogan. sysctl is the friendly front end for the tunable knobs under /proc/sys.

Kernel modules are pieces of kernel code (device drivers, file systems, network protocols) that load and unload at runtime instead of being compiled in, so you don't rebuild the kernel to add a driver. lsmod lists loaded modules, modprobe loads one and its dependencies, and rmmod removes it.

modprobe is preferred over the older insmod because it resolves dependencies and reads config from /etc/modprobe.d. Modules run in kernel space, so a buggy one can crash the whole system, which is why signed modules matter on locked-down hosts.

ext4 is the reliable general-purpose default: mature, stable, good for most workloads. XFS handles large files and high parallel throughput well, which is why it's common on big data and RHEL servers. Btrfs and ZFS add copy-on-write features: snapshots, checksums, and built-in volume management, at the cost of more complexity and memory.

The interview answer is matching the file system to the workload rather than declaring one best: ext4 for general use, XFS for large-file throughput, a copy-on-write file system when you want cheap snapshots and integrity checking.

For normal tasks the kernel uses a fair scheduler that tracks how much CPU time each runnable task has received and picks the one that's fallen furthest behind, so no task starves. Priority is expressed with the nice value, from -20 (highest) to 19 (lowest), which biases how much CPU a task gets.

Beyond that, real-time scheduling policies (SCHED_FIFO, SCHED_RR) let latency-sensitive work preempt normal tasks, and cgroups can hand a whole group a CPU share. renice adjusts a running process's niceness; ionice does the analogous thing for disk I/O priority.

Layer the defenses: SSH keys only with password login disabled and root login off, a firewall allowing only needed ports, automatic security updates, and least-privilege accounts with sudo instead of shared root. Add a fail2ban-style ban on brute-force attempts and keep the attack surface small by removing services you don't run.

Then the deeper layer: mandatory access control (SELinux or AppArmor) confining services, audited logging shipped off-box, integrity monitoring, and secrets kept out of the repo and the environment where you can. The production-ready answer frames it as defense in depth, not one silver setting.

Both are mandatory access control systems that confine what a process can do even when Unix permissions would allow more, so a compromised web server can't read files outside its policy. SELinux labels every file and process and enforces rules against those labels; it's strict and ships enabled on Red Hat distros. AppArmor confines programs by file path, which is simpler to author, and it's the default on Ubuntu.

The trade-off is granularity versus approachability. SELinux is more precise and harder to author; AppArmor is easier to reason about but path-based, so a renamed binary can slip its profile. The pragmatic coverage names both and picks per distro rather than declaring a winner.