Linux Interview Questions and Answers for 2026

Answer: Strictly, Linux is the kernel: the program that manages CPU, memory, devices, and system calls. What people call Linux day to day is a distribution: the kernel plus GNU userland, a package manager, and services, assembled by a vendor like Debian, Red Hat, or Ubuntu. Interviewers ask this to see if you know the kernel and the distribution are different layers, because it predicts whether you understand where tools like systemd or glibc actually live. Follow-up Linux interview questions almost always pick one layer and go deeper, so keep the layers separate in your head.

Answer: The terminal is the interface: originally a physical device, now an emulator window. The shell is the program running inside it that reads your commands, resolves them, and executes them; bash is the common default. The distinction matters because shell behavior, quoting, expansion, and exit codes are what scripts depend on, while the terminal is just glass. Many Linux interview questions probe exactly this layer, since that is where automation lives.

Answer: Three reasons get cited: it is free of license costs at scale, it runs headless and stays up for years, and the whole operations toolchain, SSH, systemd, containers, configuration management, is built for it. Mention also that the same kernel runs from embedded devices to mainframes, so skills transfer. That combination of cost, stability, and ecosystem is the expected shape of the answer. That trio is exactly what Linux interview questions on this topic are fishing for.

Answer: An absolute path starts from the root / and identifies one location regardless of where you are, like /var/log/syslog. A relative path is interpreted from your current working directory, so logs/syslog means something different depending on where you stand. One detail worth adding: . and .. are relative references to the current and parent directory, and scripts should prefer absolute paths because cron jobs and services do not inherit your shell’s location. Path confusion causes enough real breakage that Linux interview questions open with it constantly.

Answer: Read, write, and execute, tracked separately for the owner, the group, and everyone else. On files, read means view contents, write means modify, execute means run as a program. On directories the meaning shifts: read lists entries, write creates or deletes entries inside, execute lets you enter and access inodes within, which is why removing execute from a directory is more damaging than removing read. Octal notation packs these as 4, 2, and 1, so 755 is owner-full, everyone else read and execute. Permissions open most in-person Linux interview questions, so deliver this answer without hesitation.

Answer: It sets the owner to read and write, group and others to read only. It applies to whatever paths you pass it, so a common bug is running it against a directory tree: directories need the execute bit to be enterable, so 644 on directories locks people out. The safe recursive form is find with -type f or -type d filtering, or chmod -R u=rwX,go=rX, where the capital X adds execute only where it already makes sense. Recursive chmod traps are quiet favorites in Linux interview questions because they reveal whether you practice.

Answer: chown user:group file changes ownership and group in one call; chgrp changes just the group. Only root can hand a file to another user, which stops privilege games between accounts. Worth adding: numeric IDs are stored on the inode, so if you delete a user and reuse its UID, files the old user owned now belong to whoever holds that ID, a classic inherited-mess scenario.

Answer: It is the permission mask subtracted from default modes at file creation: a new file starts as 666 and a directory as 777, minus your umask bits. With the common 022, files land at 644 and directories at 755. A detail that earns credit: umask cannot grant permissions, only remove them, and it is inherited from the login environment, which is why services sometimes create files with surprising modes.

Answer: su switches to another user entirely, usually root, after asking for that user’s password, giving you a full root shell. sudo runs a single command with elevated privilege after checking your own credentials against policy in /etc/sudoers. The operational argument, which is the real point of Linux interview questions like this, is auditability: sudo logs who ran what, and grants can be scoped per command, while a shared root password is untraceable. Expect Linux interview questions to follow with how you would scope a sudoers rule for one command.

Answer: Root is UID 0, the account the kernel treats as exempt from permission checks. You avoid living in it because one typo has unrestricted blast radius and because day-to-day work should run with least privilege, escalating only for specific operations. Mention that many systems disable direct root SSH entirely and require an unprivileged login plus sudo, which gives you both a safety rail and an audit trail.

Answer: A package manager installs, upgrades, and removes software from signed repositories while resolving dependencies and keeping a database of what is installed. apt is the Debian and Ubuntu frontend over dpkg; dnf is the RPM-world successor to yum on Fedora, RHEL, and derivatives. The workflow is the same shape: refresh metadata, install or upgrade, remove. Adding that packages can also hold config under /etc that upgrades try to preserve shows you have upgraded real machines.

Answer: systemctl start nginx, stop, and restart act on the running state now; enable wires the unit into the boot default so it starts on reboot, and disable unwires it. The pair people forget: systemctl status nginx shows state plus recent log lines, and restart is not the same as reload, which asks a running daemon to reread config without dropping connections when it supports that. Restart versus reload separates book answers from lived experience in Linux interview questions.

Answer: It is the init system and service manager: PID 1 on modern distributions, responsible for starting units in dependency order, supervising them, restarting them per policy, and unifying logging through the journal. Units come in types, services, mounts, timers, sockets, and each declares relationships like After and Requires. Most Linux interview questions about operations route back here, because restart policies, dependency ordering, and journal logs all live in systemd. Because systemd owns operations, half of all practical Linux interview questions resolve to a systemctl or journalctl answer.

Answer: The systemd journal indexes logs centrally; query it with journalctl, filtered like journalctl -u nginx for a unit, or -f to follow, or --since "1 hour ago". Classic plain-text logs still live under /var/log, such as syslog, auth.log, or package-specific files. The useful nuance: journal storage may be volatile across reboots unless configured persistent, and files under /var/log are rotated, so old data sits in compressed archives you read with zgrep or journalctl --file. Log fluency is why this topic anchors the operational half of Linux interview questions.

Answer: ps aux gives a snapshot of every process with CPU and memory columns; top or htop gives the live sorted view; pgrep finds PIDs by name for scripting. A good detail: ps aux shows %CPU as a lifetime average, so a process that used to spin can look hot in ps while idle now, which is why live tools matter. Know ps -ef too, since some shops’ runbooks use that form.

Answer: kill PID sends SIGTERM, a polite request the process can catch to flush state and shut down cleanly. kill -9 sends SIGKILL, which the kernel enforces with no notice to the process, so files may be left mid-write and locks left behind. The professional habit this tests: escalate, never start at 9, because SIGTERM exists precisely so programs can exit correctly. Signal discipline is one of the oldest patterns in Linux interview questions, and it never stopped being graded.

Answer: Ctrl+Z suspends the foreground job, sending it the stop signal; bg resumes it in the background; fg brings it back to the foreground. jobs lists what the shell is tracking. The caveat worth stating: a backgrounded job is still attached to your terminal session, so when the session dies the shell sends it a hangup signal, which is why long-running work needs nohup, disown, or a proper service unit. Hangup behavior leads directly into Linux interview questions about nohup and lost overnight jobs.

Answer: They are per-process string values inherited by children, read by programs for configuration like PATH, HOME, or API endpoints. Export one for the session with export VAR=value; make it permanent for your user in ~/.bashrc or the login file your distro reads, or system-wide under /etc/environment or profile files. A sharp addition: a variable set in your shell does not affect an already-running service, so changing config for a daemon means editing its unit environment and restarting it.

Answer: It is the ordered, colon-separated list of directories the shell searches for command names. First match wins, which is why which cmd matters: it tells you which binary you would actually run. Shadowing is the classic lesson, a stray ./node_modules/.bin early in PATH changes which tool executes, and security-conscious setups keep . out of PATH entirely so a downloaded script named ls cannot hijack anything. Shadowing turns this small topic into one of the security-flavored Linux interview questions.

Answer: Every command finishes with a numeric status: 0 means success, nonzero means failure, and $? holds the last command’s code. Conventions reserve 1 and 2 loosely for general errors and misuse, while specific programs document their own. Scripts should check it or set -e, and pipelines need attention because the exit code is the last command’s unless you use set -o pipefail, a nuance that separates people who write real scripts from people who copy them. Exit codes appear in Linux interview questions for every role, because scripts fail silently without them.

Answer: A pipe, |, connects one command’s stdout to the next command’s stdin, letting tools compose: ps aux | grep nginx. Redirection rewires a command’s input or output to or from files: > creates or truncates, >> appends, 2> captures stderr. The pair to know together is 2>&1, which sends stderr where stdout currently points, and its ordering matters, since >file 2>&1 and 2>&1 >file do different things. Ordering traps like this make redirection a reliable differentiator in written Linux interview questions.

Answer: grep pattern file finds matching lines, with -i ignoring case, -r recursing, -n numbering lines, and -v inverting. For locating files by name, size, or age, find /path -name "*.log" -mtime +7 is the workhorse, and -exec or a pipe into xargs acts on results. Interviewers often ask the difference in intent: grep answers what text lives where, find answers which files match a predicate. Pairing them cleanly is what Linux interview questions here are really checking.

Answer: head prints the first lines of a file, tail the last, and tail -f follows a growing file, which is how everyone watches live logs. Useful flags: -n 50 for line counts, -F instead of -f when the file will rotate, because -F reopens the new file rather than staring at the renamed old one. That rotation detail is a small thing that signals real operational experience.

Answer: tar -czf out.tar.gz paths creates a gzipped tarball, tar -xzf out.tar.gz extracts, and the letters are worth knowing rather than memorizing whole incantations: create, extract, gzip, file. For single files, gzip and gunzip or the newer zstd and xz do the job with different speed and ratio tradeoffs. One safety note worth saying out loud: extracting an archive with absolute paths or .. entries can write outside your target, so inspect unknown archives first with -t.

Answer: df -h reports free space per mounted filesystem by asking the filesystem itself; du -sh /path adds up sizes by walking files. They can disagree, and the disagreement is diagnostic: if df says full but du finds little, space is probably held by deleted files that running processes still have open, or by another mount shadowing a directory. This pair is one of the most common Linux interview questions because it is the first step of the most common disk incident. This pair anchors the most common scenario in Linux interview questions, so keep both commands ready.

Answer: It shows total, used, free, and available memory plus swap. buff/cache is the kernel using spare RAM to cache disk data, which is harmless because it is reclaimed on demand, so available is the column that answers can this box take more load, not free. The classic beginner mistake this question tests: declaring a memory emergency because free is near zero on a healthy, busy Linux box. Available versus free is the entire lesson of this entry in Linux interview questions.

Answer: uptime or top shows three exponentially smoothed numbers: runnable plus uninterruptible tasks over 1, 5, and 15 minutes. Read them against core count: 4.0 on a 4-core box means roughly every core has one thing to do, while 4.0 on 16 cores is quiet. The nuance that earns points: on Linux the numbers include D-state tasks, so rising load with low CPU often means an I/O or storage problem, not a compute one. Reading load against cores is the interpretation half that Linux interview questions grade here.

Answer: A symlink is a small file holding a path; delete the target and the link dangles. A hard link is a second directory entry pointing at the same inode, so both names are equally the file, and the data survives until every link is deleted. Hard links cannot cross filesystems or point at directories; symlinks can. You can demonstrate mastery by adding that ls -l shows a link count on every file, because every file is already hard-linked at least once. Link mechanics surface early in Linux interview questions because they expose inode understanding cheaply.

Answer: The inode is the filesystem’s record of a file: size, ownership, mode, timestamps, and pointers to data blocks. The name is just a directory entry mapping a string to an inode number. This design explains a surprising number of behaviors: hard links share one inode, a file can be zero-length yet hold a name, and a filesystem can run out of inodes while having free space. At beginner level, the expected summary is metadata lives in the inode, names live in directories. Say that sentence and most follow-up Linux interview questions become hard link or disk full scenarios.

Answer: Seven colon-separated fields: username, legacy password placeholder, UID, primary GID, comment or GECOS, home directory, and login shell. Password hashes live in /etc/shadow, readable only by root, precisely because /etc/passwd must be world-readable for name lookups. A good example to quote: root:x:0:0:root:/root:/bin/bash, and note system users like www-data have /usr/sbin/nologin as their shell.

Answer: ssh user@host opens an encrypted session; with keys, your client proves possession of a private key, while the server checks the matching public key listed in the account’s ~/.ssh/authorized_keys. The private key never crosses the wire. Know ssh -i keyfile for explicit keys, -p for a nonstandard port, and that clients refuse world-readable private keys, which is the single most common first-time SSH support ticket. SSH opens nearly every remote-work block of Linux interview questions, so make the key flow automatic.

Answer: Cron is the classic scheduler: a daemon that wakes each minute and runs jobs whose five time fields, minute, hour, day of month, month, day of week, match now. 30 2 * * * runs nightly at 02:30. Edit with crontab -e, list with crontab -l. Two details that show depth: cron runs with a minimal environment and a different working directory, so scripts that work in your shell often fail there, and modern boxes increasingly prefer systemd timers because they log, depend, and catch up better. The cron versus timers comparison is a guaranteed neighbor topic in Linux interview questions.

Answer: curl -O url saves a remote file, curl -I shows headers, and curl speaks many protocols, which makes it the general HTTP debugging tool as much as a downloader. wget is the other classic, strong at recursive downloads and resuming. On locked-down hosts where neither exists, people fall back to ssh host 'cat remotefile' > local, and knowing that trick plays well in Linux interview questions about restricted environments.

Answer: which cmd prints the first executable found in PATH. whereis cmd searches standard locations for the binary, sources, and man page. type cmd is the shell builtin that reveals what a name actually resolves to: an alias, a function, a builtin, or a file, which makes it the most truthful of the three. Leading with type when answering is a small credibility win because it shows you know aliases can masquerade as commands. Small answers like this are confidence checks inside Linux interview questions, so keep them crisp.

Answer: man cmd for the full manual, searchable inside with /term; cmd --help for a quick usage summary; man -k keyword or apropos to find the right page when you only know the concept. Worth mentioning: section numbers matter, so man 5 crontab documents the file format while man 1 crontab documents the command, and knowing that sections exist is the part beginners miss. Knowing the manual’s structure is a small edge that compounds across Linux interview questions.

Answer: The shell keeps recent commands in memory and writes them to ~/.bash_history. history lists them, Ctrl+R searches interactively, and !$ or !! reuse the last argument or command. Useful knobs: HISTSIZE and HISTFILESIZE for retention, HISTCONTROL=ignoredups to cut noise, and the caution that secrets typed into commands persist in history, which is why tokens belong in files or credential tools, not command lines.

Answer: /etc/hosts maps names to IPs locally, and the resolver consults it before DNS under the default nsswitch.conf order. It matters in practice for pinning a name during migrations, testing a new server before cutting DNS over, and breaking, famously, when someone leaves a stale entry behind. Interviewers like this one because the failure mode is subtle: everything else about DNS is fine, yet one box resolves differently. That subtlety is why hosts-file questions survive in Linux interview questions year after year.

Answer: The machine’s name, shown by hostname or hostnamectl, used in prompts, logs, and clustering logic. Modern systems change it with hostnamectl set-hostname newname, which updates the transient and static names; also check /etc/hosts so the box can still resolve itself, or some services stall on lookup at startup. Naming conventions are worth one sentence: predictable, environment-prefixed names make incident triage dramatically faster.

Answer: The shell parses the line, expands aliases, variables, and globs, then checks whether the command word is a builtin or function. If not, it walks PATH in order until it finds an executable, then calls fork() to clone itself and execve() in the child to replace that copy with the binary. The parent waits, collects the exit status, and prompts again. Saying fork and exec, and noting redirections are set up before exec, is exactly what this question is fishing for. It is one of the highest-signal Linux interview questions because the answer grows with your seniority.

Answer: R is running or runnable, S is sleeping on a near-term event, D is uninterruptible sleep, usually I/O the kernel cannot safely abort, Z is zombie, exited but unreaped, and T is stopped by job control. The two that matter operationally: a pile of D-state processes points at storage or NFS trouble and ignores every signal, and zombies indicate a parent that is not calling wait(). Interviewers use this question to route you: operators know the letters, engineers know what each implies. Keep this mapping handy; scenario-tier Linux interview questions lean on it constantly.

Answer: A zombie has already exited; all that remains is a process table entry holding its exit status for the parent to read. You cannot kill it, it is already dead. It disappears when the parent calls wait(), or when the parent dies and systemd re-adopts the child and reaps it. So the fix is the parent: find it with ps -o ppid= -p ZOMBIE_PID, and restart or repair it. A long-lived parent leaking zombies has a bug in its child handling.

Answer: fork() duplicates the calling process; both copies continue from the same point, distinguished by the return value. execve() replaces the current process image with a new program, keeping the PID. Unix shells combine them: fork a child, wire up pipes and redirections in the child, exec the target. Worth adding that posix_spawn exists as a lighter-weight alternative, and that threads use clone() with shared addresses rather than true forks, which is why container runtimes talk about clone flags. This mechanism is among the most repeated entries in Linux interview questions across every seniority level.

Answer: On Linux, load counts runnable tasks plus tasks in uninterruptible disk sleep, so a box streaming heavy I/O can show load above core count while CPUs are mostly idle. That is why you pair it with observation: top or mpstat for CPU, iostat -x for device pressure. A rising 15-minute load with low %wa means compute saturation, while high load with high await means storage. Reading all three windows together, 1, 5, 15, tells you whether pressure is climbing or draining. That three-window reading is the layer Linux interview questions are really probing on load.

Answer: nice -n 10 cmd lowers a process’s CPU scheduling priority; only root can raise priority, negative values. It affects CPU time slices, not much else, which is the common misconception. ionice -c3 marks a process as idle-class for I/O scheduling, perfect for batch jobs you never want competing with production reads. The honest framing: on modern kernels with many cores, nice matters less than people expect, and cgroup limits have largely replaced it for serious resource control. Knowing when a tool has been superseded is the maturity signal Linux interview questions like this one hunt for.

Answer: Resource limits per process: open files, locked memory, CPU seconds, process count, core size. See the current shell with ulimit -a; soft limits the process can raise, hard limits it cannot exceed. Persistent config lives in /etc/security/limits.conf plus limits.d, applied at login by PAM. The classic production incident: a daemon hits the default 1024 file descriptors under load and starts refusing connections, and the fix is a drop-in raising nofile for that service unit, since systemd services do not read limits.conf. That exception is what turns ulimits from trivia into one of the practical Linux interview questions.

Answer: Cgroups account and limit resources, CPU, memory, I/O, pids, for groups of processes; namespaces isolate views of the system: pid, network, mount, UTS, IPC, user, cgroup. Together they are the machinery under containers: a container is ordinary processes with a namespace per dimension and a cgroup budget, no virtual machine involved. This answer is increasingly one of the most valuable Linux interview questions for DevOps roles, because half the debugging you will do on Kubernetes is these two primitives misbehaving. Container-heavy Linux interview questions route through this answer more often than any other theory topic.

Answer: Physical volumes are block devices or partitions initialized for LVM; a volume group pools their capacity; logical volumes are carved from that pool and carry filesystems. The win is flexibility: grow a filesystem online with lvextend plus resize2fs or xfs_growfs, add a disk to the group with vgextend, take snapshots for backups. Mention the thin-provisioning option if you want depth, and that XFS grows but does not shrink, which decides your resize procedure. Storage flexibility is why LVM holds its long-standing place in Linux interview questions.

Answer: nofail tells the boot not to wedge if that device is missing, dropping to a degraded but reachable system instead of an emergency shell waiting for a disk that will never appear. It pairs with _netdev for network filesystems so mounting waits for networking. This is a beloved config-management war story: one typo in /etc/fstab without nofail turns the next reboot into an outage, which is why fstab changes get a mount -a test and a findmnt check before anyone logs out. Every veteran’s collection of Linux interview questions war stories includes one of these reboots.

Answer: Swap is disk space the kernel uses to page out cold anonymous memory; swappiness, 0 to 100, biases how eagerly it does that relative to reclaiming page cache. Defaults near 60 suit desktops; latency-sensitive servers often set 10 or 1 so the kernel prefers reclaiming cache over paging app memory. Check with free -h and cat /proc/sys/vm/swappiness, set at runtime via sysctl and persist it in /etc/sysctl.d. Add that some databases explicitly want swap present but reluctant, as insurance against OOM. Tuning intent matters more than the number, which is the layer Linux interview questions grade on this topic.

Answer: When memory and reclaim options are exhausted, the kernel invokes the out-of-memory killer, which selects the task with the worst oom_score, roughly badness proportional to memory footprint, weighted by oom_score_adj. You can read a process’s score in /proc/PID/oom_score and pin critical daemons with a negative adj like -1000. Evidence of a kill lands in dmesg or the journal as Killed process lines. The strong answer mentions reserving honest headroom, cgroup memory limits, and that many mysterious service deaths are this, not crashes. Reframing a crash as a kernel decision is the insight this entry in Linux interview questions rewards.

Answer: By default many distros store the journal volatile under /run/log/journal, wiped at boot, so journalctl -b -1 shows nothing. Persistent storage starts by having /var/log/journal exist with Storage=persistent in journald.conf, then restarting systemd-journald. Size caps come from SystemMaxUse, and vacuuming frees space with journalctl --vacuum-size=500M. Pair the journal with rsyslog when you need classic flat files or shipping to a central platform.

Answer: Logrotate renames, compresses, and prunes log files on a schedule, then signals daemons to reopen them, usually via a postrotate hook. Config per application lives under /etc/logrotate.d with directives like daily, rotate 14, compress, missingok, notifempty, and copytruncate for programs that cannot reopen logs. The interview angle is failure modes: rotation without reopen writes keep flowing into the renamed inode until the disk fills, the same deleted-open-file trap as df versus du. Connecting rotation to that trap lifts your answer above the parroted versions most Linux interview questions receive.

Answer: Beyond .service: .socket for socket activation, .timer for scheduling, .mount and .automount, .path to trigger on filesystem events, .target as grouping and synchronization points, .slice for resource hierarchy, and .device. Knowing at least service, timer, socket, and target is table stakes; adding that sockets and path units enable lazy and event-driven startup shows you think about boot time and dependency design rather than just start scripts. Unit-type fluency signals design thinking, which is why it persists in Linux interview questions.

Answer: systemctl edit nginx opens a drop-in override at /etc/systemd/system/nginx.service.d/override.conf, holding only the changed keys, which survive package upgrades. Structural edits need [Service] and a reset like ExecStart= on its own line before redefining it, because lists append otherwise. After edits, daemon-reload then restart. Mention systemctl diffing against vendor defaults and reverting with systemctl revert, and you have covered the operational loop completely.

Answer: Targets replace runlevels: multi-user.target is a full networked system without GUI, graphical.target adds the display stack, rescue.target boots a single-user environment with local filesystems for repairs, and emergency.target goes further, only the root filesystem read-only and no services, for when even rescue will not come up. You switch with systemctl isolate and set the boot default with systemctl set-default, and pass systemd.unit=rescue.target on the kernel line when the system will not boot normally. Rescue versus emergency is one of the oldest entries in the Linux interview questions canon and still separates candidates.

Answer: systemd-analyze prints total boot time split by firmware, loader, kernel, and userspace; systemd-analyze blame ranks units by activation time; critical-chain shows the dependency path that gated the default target. Typical wins are services blocking on network or DNS timeouts, masked unneeded units, parallelizing via correct dependency declarations instead of naive After chains, and moving one-shot work into timers. Naming a real number you achieved, with the unit that was the culprit, turns this answer into a story. Numbers plus a culprit is the shape that makes Linux interview questions answers memorable.

Answer: -L 8080:db.internal:5432 listens locally on 8080 and tunnels connections through the SSH server to that internal target, your everyday access-to-a-private-service pattern. -R does the reverse, exposing a local service to the remote side, and -D 1080 builds a SOCKS proxy through the box. Add the flags that make it production-safe: bind address control, -N for no shell, and the governance point that tunnels bypass network segmentation, so many shops restrict them deliberately.

Answer: The agent holds decrypted keys in memory and answers signing requests, so you load a passphrase-protected key once with ssh-add and never retype the passphrase, and forwarding with -A lets a jump host authenticate onward using your local key without copying private material to it. The security caveat to volunteer: agent forwarding hands the socket to anything that can reach it on the remote host, so use it only to hosts you trust, and prefer ProxyJump for pure transit these days. The trust caveat is what makes this entry in Linux interview questions a security check in disguise.

Answer: scp copies whole files over SSH every time. rsync -avz --partial compares metadata and transfers only changed blocks, resumes interrupted runs, preserves permissions, ownership, and timestamps with -a, and can delete stragglers with --delete, which you treat as a loaded weapon and dry-run with --dry-run first. For directory trees, migrations, and backups over SSH, rsync wins decisively; for one file, scp is fine and simpler.

Answer: Setuid on an executable runs it with the file owner’s identity, the mechanism behind passwd writing to shadow; setgid on a binary runs with the group’s identity, and on a directory makes new files inherit the directory’s group, the teamwork permission; the sticky bit on a directory, /tmp‘s 1777, lets anyone create files but only owners delete their own. Find them with find / -perm /6000 and -perm -1000. Auditing these is standard hardening, because a forgotten setuid binary is a privilege escalation path. Auditing reflexes like this are why security-adjacent Linux interview questions keep this topic alive.

Answer: ACLs attach per-user and per-group permissions beyond the single owner-group-other triple: setfacl -m u:deploy:rx /srv/app, read back with getfacl. The plus sign after the mode bits in ls -l marks their presence. They shine for shared trees with mixed teams and for service accounts that need narrow access to specific paths, and the default ACL variant stamps new files created in a directory, which is how you stop every new file from being unreadable to the team.

Answer: Capabilities split root’s monolithic power into named units like CAP_NET_BIND_SERVICE to bind ports under 1024 or CAP_NET_RAW for raw sockets, granted to executables with setcap and inspected with getcap. The payoff: a small tool can bind port 80 without being setuid root. Container contexts lean on this hard, since runtimes drop most capabilities by default, and add exactly the capability the app needs is both good security and a great interview sentence.

Answer: Both are mandatory access control layers stacked on top of ordinary permissions. SELinux labels everything and polices label-to-label access by policy, with modes enforced, permissive, disabled, checked via getenforce and diagnoses via ausearch -m avc; AppArmor profiles individual programs by path instead. The interview expectation is not policy authorship, it is recognizing denials: when permissions are provably correct but access fails with a permission error, check whether the MAC layer blocked it before blaming the app. Recognizing the MAC layer is the working half of SELinux entries in Linux interview questions.

Answer: chroot changes a process’s view of the filesystem root to a directory, containing it to that subtree; classic uses include installing systems from a live environment and isolating old daemons. Its limits matter: it is not a security sandbox for root, root can escape via saved file descriptors or chroot again, and only the filesystem namespace is isolated, no network or PID separation. Saying it is containment of path resolution, not isolation of privilege is the precise sentence interviewers want.

Answer: ip addr shows interfaces and addresses, ip link state, ip route the routing table, all from iproute2, the successor to the deprecated net-tools, so ifconfig and route are legacy equivalents you may meet on old boxes. Useful one-liners: ip -br addr for the terse view, ip route get 8.8.8.8 to see which interface and gateway the kernel would actually use for a destination, which is a fantastic shortcut in routing questions.

Answer: ss -tlnp lists TCP listeners with owning PIDs, -u adds UDP; lsof -i :8080 answers the same question by file descriptors, and fuser 8080/tcp is the terse third option. On hosts where the process column is missing, you lack privileges or the socket belongs to another network namespace, a container, for instance. This question is a near-guarantee in any ops loop because it is step one of port already in use and of why is this service exposed.

Answer: The C library resolver follows /etc/nsswitch.conf order, typically hosts: files dns, so /etc/hosts wins first, then DNS per /etc/resolv.conf, which names nameservers and search domains. On systemd systems, a local stub resolver at 127.0.0.53 may forward, with per-link config from network manager or systemd-networkd. Diagnostics follow the same path: getent hosts name tests the full chain, dig name tests DNS alone, and the split is exactly how you isolate hosts-file stumbles from resolver outages. That isolation habit is the engineering half of DNS work in Linux interview questions.

Answer: curl -v url prints the connection, TLS, request, and response with headers; -I for a HEAD, -H to inject headers, -x for a proxy, --resolve host:443:IP to test a specific backend before DNS cuts over. Read status and timing deliberately, and use -w with timing variables to measure where latency lives. The habit this tests: separating DNS, connect, TLS, and server time instead of declaring the API is slow from one number. Timing decomposition is the discipline that separates strong answers in Linux interview questions about HTTP.

Answer: It captures packets off an interface with BPF filters: tcpdump -ni eth0 port 443, where -n skips name lookups and -i any spans interfaces. For real analysis, write a ring buffer to files with -w and open in Wireshark. On TLS traffic you will not see payload, but you see the handshake, who reset, retransmissions, and silence, which answers reachability questions in seconds. The discipline to state filters narrowly, and to capture on the right hop, is what the question grades.

Answer: A virtual filesystem the kernel populates live: per-process directories with status, cmdline, fd, limits; system-wide cpuinfo, meminfo, loadavg, mounts, and tunables under /proc/sys. Nothing on disk exists; reading it asks the kernel. Working favorites: /proc/PID/fd to see open files including deleted-but-held ones, /proc/meminfo for real memory math, and /proc/PID/limits to confirm what a daemon’s ulimits really are at runtime. Runtime truth over documentation is the instinct Linux interview questions on /proc are testing.

Answer: Sysfs at /sys exposes kernel object structure: devices, buses, drivers, block devices, network devices, organized by their topology rather than by process. You use it to read disk scheduler for /sys/block/sda/queue/scheduler, NIC settings, LED and hardware state, and to see cgroup v2 controllers under /sys/fs/cgroup. The clean sentence: /proc answers what are my processes and kernel settings, /sys answers what devices exist and how are they configured.

Answer: Runtime: sysctl -w vm.swappiness=10, listed via sysctl -a or read directly from /proc/sys. Persistent: drop a file in /etc/sysctl.d/99-tuning.conf with vm.swappiness=10 and apply with sysctl --system. Names map to paths, dots become slashes. Documenting the why in the drop-in file matters operationally, because six months later nobody remembers why inotify watches were raised or BPF was disabled. Documented intent is what separates professional tuning from cargo cult in Linux interview questions.

Answer: Loadable kernel code for drivers and features: lsmod lists loaded modules, modprobe modname loads with dependency resolution, modprobe -r unloads when reference counts allow, and modinfo shows version and parameters. Persistent config like options and blacklists lives under /etc/modprobe.d. The practical context: missing storage or network drivers in the initramfs are boot blockers, and exotic hardware often needs a module parameter tuned, which is where this stops being trivia.

Answer: strace cmd traces system calls; -p PID attaches to a live process, -e trace=openat,connect narrows the noise, -f follows children, -T and -c time and summarize. It answers the questions debuggers do not: which config path did it actually read, which address did it really connect to, is it blocked in read() or spinning. The caveat to state: tracing slows the target and needs ptrace rights, so on hardened or containerized hosts you may need privileges or an eBPF alternative. Knowing a tool’s cost is part of every strong answer to tracing questions in Linux interview questions.

Answer: Everything is a file, so lsof cross-examines the system: lsof -i :443 for socket owners, lsof /var/log/big.log to find who holds a file, lsof +D /path for a directory tree, lsof -p PID for one process’s world, and lsof +L1, the incident classic, listing deleted files still held open and eating space. Read-only by nature and safe on production, which makes it the first honest step in many forensic runs. Safety plus reach is why lsof earns its permanent spot in Linux interview questions.

Answer: Cron wins for simple user-level schedules and universal familiarity. Timers win on everything operationally hard: they log to the journal, carry dependencies and resource limits from unit config, support calendar and monotonic schedules like 15 minutes after boot, avoid overlap natively, and can run missed jobs on next boot with Persistent=true. The expected judgment: new infrastructure jobs deserve timer units; cron persists for quick personal schedules and very old fleets. The judgment, not the syntax, is what Linux interview questions on scheduling are after.

Answer: -e exits on any command failure, -u errors on unset variables instead of silently expanding empty, -o pipefail makes a pipeline fail if any stage fails, not just the last. Together they convert quiet corruption into loud failure, which is exactly what you want in automation. Nuances that show depth: some commands are expected to fail and need guards like cmd || true, and -e does not fire inside conditionals, so tests belong in explicit if statements.

Answer: trap 'cleanup' EXIT runs handlers on exit, and additional traps on INT or TERM handle signals: delete temp files, release locks, kill children, print the failing line with a LINENO trap on ERR. It is the difference between a script that leaves half-deployed state behind and one that rolls back. A strong answer notes traps fire in order of definition on exit, and that cleanup handlers must be re-entrancy safe when they kill their own process group.

Answer: First, df -h to see which filesystem is full and whether it is the root or a data mount. Then check deleted-but-open files: lsof +L1 | sort -k7 -n, because a process holding a rotated or deleted log keeps the space allocated until it exits or closes the descriptor; restart or signal the holder. Next, df -i for inode exhaustion, since a filesystem can be full of metadata with free space. Last, look for mount shadowing: a directory that used to be a mount point can hide data behind a new mount. That ordered story is the entire question. It is also the most frequently repeated of all scenario Linux interview questions.

Answer: Something created a colossal number of tiny files: mail queues, cache directories, session files, or a runaway loop writing crumbs. Confirm with df -i, then hunt the densest trees with find /var -xdev -type f | cut -d/ -f1-5 | sort | uniq -c | sort -n | tail to see where the millions live. Fix the generator first, delete safely with find path -type f -name pattern -delete in bounded batches, and remember inode count is fixed at mkfs time on ext-family, so prevention means directory design, not more space. Prevention framing is what elevates answers to scenario Linux interview questions like this one.

Answer: I narrate a funnel: uptime for load trend against core count; top sorted by CPU then memory, watching %wa for I/O wait; free -h for available memory and swap activity; df -h to rule out a full disk breaking writes; iostat -x 2 5 for device await and utilization; vmstat 2 5 for run queue and context switches; dmesg -T | tail for OOM kills or hardware errors; then ss -s and service logs for connection pressure. The habit being tested: measure before touching, and narrate each step’s decision, because in scenario rounds the method is the answer. Rehearse the funnel out loud; scenario Linux interview questions grade the narration as much as the knowledge.

Answer: Identify it with top pressed P, then get context: ps -o pid,ppid,user,etime,cmd -p PID for age and parent, cat /proc/PID/status for state and threads. Distinguish spin from block: pidstat -p PID 1 shows CPU split, cat /proc/PID/stack or strace -p PID shows whether it is executing or stuck in a syscall. Then decide with ownership: is this the workload growing, a retry loop, or a leak? The kill versus fix conversation, out loud, is what interviewers want to hear next.

Answer: Track the top residents over time: ps aux --sort=-rss | head in a loop or from monitoring, because a leak shows as one process’s RSS climbing monotonically. Confirm with pmap -x PID to see which mappings grow, and grep -E 'VmRSS|VmSwap' /proc/PID/status for precise numbers. Rule out the innocent explanation first, page cache is not a leak, by reading available memory, not free. If it is a shared library or heap pattern, hand the engineers pmap snapshots over time; if it is cache growth inside an app like memcached, that is configuration, not a bug.

Answer: D state means an uninterruptible kernel wait, almost always block I/O: a hung NFS server, a dead SAN path, a failing disk. No signal will help because the process has no userspace to receive it. Find the wait point with cat /proc/PID/stack or echo w > /proc/sysrq-trigger then dmesg, identify the backing mount with lsof PID or mount | grep, and fix the I/O path: restore the NFS server, fail over the path, or force-unmount with umount -f -l as a last resort. The kernel-side rule, stated plainly, is the whole answer. D-state stories are staples of SRE-flavored Linux interview questions for exactly this reason.

Answer: Zombies are unreaped children, so I ignore the zombies and fix the parent. Find it via ps -o ppid= -p PID, check what it is with ps -o cmd= -p PPID, then restart it if it is a worker daemon, or fix its child-reaping code if it is homegrown, a missing wait() in a SIGCHLD handler is the usual bug. Killing zombies directly is impossible and killing the parent without a plan just re-parents them to systemd, which reaps them, which is actually a legitimate emergency move. Saying that last part with confidence tends to end this line of questioning well.

Answer: systemctl status myapp for the exit code and recent lines, then journalctl -u myapp -n 100 --no-pager for the actual error, which usually names the file and line. Run the daemon’s own config test if it has one, nginx -t, sshd -t, before restarting anything. Check for the classics: syntax typo, wrong ownership, a port held by another listener via ss -tlnp, or a changed unit file needing daemon-reload. Roll back the change from backup if the finding takes longer than the outage can bear, then fix forward. Config test before restart is the sentence they are listening for.

Answer: systemd could not mount something in /etc/fstab and stopped for a console. Log in, read the error, fix the line: wrong UUID, missing device, or a typo. The lesson to articulate: test every fstab edit with mount -a and findmnt --verify before rebooting, add nofail to non-critical mounts, and keep console access working, because this failure mode always arrives on the worst night. If the root filesystem itself is mislisted, you boot a rescue image and repair from outside, which is why rescue media access is part of the answer. Boot disasters like this are why war stories dominate senior Linux interview questions.

Answer: Work the ladder: lsattr first, because the immutable attribute i or append-only a blocks modification until chattr -i clears it. Then check it is not a mount point with findmnt target, since deleting a mounted-onto directory fails. Check the filesystem is not mounted read-only with mount | grep. On RHEL-family boxes, an SELinux label denial can masquerade as permission trouble, so ausearch -m avc -ts recent. Bare ls -l showing 777 proves nothing about any of these layers, which is the teaching point of the question.

Answer: Walk the full path with namei -l /srv/app/data/file, because execute permission on every intermediate directory is required and usually the culprit. Then check the process’s real identity, not yours: ps -o user,group -p PID and supplementary groups via id user. Consider ACLs with getfacl, a mandatory access control denial via the audit log, a read-only mount, and on containers the user mapping that makes your root actually nobody inside. Nine times out of ten it is a parent directory missing the execute bit, and saying that first shows pattern experience.

Answer: Preview first: find /data -xdev -type f -mtime +30 | wc -l and eyeball a sample. Then delete in bounded, logged batches: find /data -xdev -type f -mtime +30 -print0 | xargs -0 -n 1000 rm -f, or -delete on GNU find. The -print0/-0 pair defends against spaces in names, batching avoids the argument-list-too-long error and softens I/O spikes, and -xdev keeps you from wandering into other filesystems. Mention off-peak execution and a dry-run flag in the wrapper script, and this answer is complete.

Answer: The shell expanded millions of names into one argv, and argv has a finite size. The fix is to let one program iterate instead: find dir -type f -delete, or batch with find dir -type f -print0 | xargs -0 -n 1000 rm. Deleting the whole tree can also be mkdir empty && rsync -a --delete empty/ dir/, a trick that is often fastest of all. The cause explanation is the graded half, because it proves you know the shell expands globs before the command ever runs.

Answer: A process still holds the deleted file open, so its blocks are not free until that descriptor closes. Find the holder with lsof +L1 or lsof | grep deleted. Two remedies: gracefully restart or signal the holder to reopen logs, which is the clean fix, or recover content first through /proc/PID/fd/N by copying it elsewhere if the data matters. Then prevent it: rotate with copytruncate only for daemons that cannot reopen, and prefer logrotate’s postrotate reopen signal. This is the single most-asked disk scenario in Linux interview questions, and the /proc recovery trick is the detail that makes it memorable. If you retain one scenario from this bank of Linux interview questions, make it this one.

Answer: ss -tlnp | grep :8080 names the current owner; lsof -i :8080 works equally well. Then decide: kill the stale process if it is leftover, fix the app’s port config if it collides with a legit neighbor, or find the TIME_WAIT subtlety, where a restarting server without SO_REUSEADDR cannot rebind for a minute, and the fix is in the app, not the system. In containers, check the host side of the published port mapping too. Naming the TIME_WAIT case is the bonus that separates senior answers.

Answer: Work outward in: can you ping, is port 22 open with nc -vz host 22, does ssh -v get past TCP, key exchange, auth? On the path: firewall or security group change, fail2ban or DenyHosts locking your IP after retries, VPN or bastion outage. On the host: sshd running, config syntax after an edit, disk full breaking writes to auth logs or home, PAM problems, expired accounts. On the client: key permissions 600, wrong key offered, known_hosts conflict after a rebuild. The order, network then host then auth, is what the interviewer scores, not luck. Structured order under pressure is the entire point of SSH rounds in Linux interview questions.

Answer: iostat -x 2 confirms which device and how bad await is; then iotop -oPa ranks processes by actual I/O, which usually ends the investigation. Corroborate with pidstat -d 2 and, for the curious, block_dump or eBPF tools on modern kernels. Then the judgment call: is this a backup or batch job that should be ioniced and scheduled off-peak, a database that needs its own device, or failing hardware masquerading as load, hinted by rising await with low throughput and errors in dmesg. Read dmesg before blaming the workload, always.

Answer: Working set exceeded RAM, so the kernel is paging out hot pages; latency collapses. Confirm with vmstat 1, si/so columns active, and free -h showing low available. Relieve it: stop or throttle the biggest resident, add memory if this is chronic, fix the misconfigured cache or worker count that overcommitted, and consider a service’s cgroup memory limit so one tenant cannot starve the host. Check dmesg for near-OOM events afterward. The prevention sentence: capacity alerts on available memory, not free, firing long before swap becomes the story. Capacity thinking is what lifts this above the average answer to Linux interview questions about memory.

Answer: Time skew. timedatectl for status and whether NTP sync is active, chronyc tracking or ntpq -p for offset and source health. TLS, Kerberos, JWT validation, and cron clusters all break in weird ways when clocks drift. Fix the sync service, verify the offset shrinks toward zero, and add skew monitoring. Mentioning that virtualized guests drift when their host throttles, and that hardware clock mistakes on dual-boot machines cause one-time jumps, rounds the answer out. Clock topics are sneaky favorites in Linux interview questions because the symptoms masquerade as app bugs.

Answer: The 2026 answer is a systemd unit: a .service with correct After/Requires relationships, Type=oneshot plus RemainAfterExit for one-time work, resource limits for free, and journal logging, enabled with systemctl enable. Cron’s @reboot exists but misses ordering guarantees and logging. Legacy rc.local is disabled and deprecated on modern distros. Saying why beats naming: ordering, supervision, and observability are the three things a boot-time job always ends up needing.

Answer: rsync -aHAX --numeric-ids src/ target:/dst/: archive for modes, times, symlinks; -H for hard links; -A and -X for ACLs and extended attributes; numeric IDs when the UID maps differ between machines. Run it ahead of time, then a final delta pass during cutover, because the second pass moves only changes. Verify with a dry-run diff pass and du comparisons, and mind the trailing-slash semantics that trip everyone once. Tar-over-ssh is the acceptable alternative when rsync is unavailable, with the same verify step. Verification is the quiet differentiator between confident and lucky answers in Linux interview questions.

Answer: On logout the session’s processes receive SIGHUP; unless the program ignores it, they die. Prevention, in order of preference: run real work as a service, systemd-run --unit myjob cmd even ad hoc, so it gets supervision and logs; use nohup cmd & or disown for quick cases; keep work inside tmux or screen when you need to reattach interactively. The cause first, then the ranked fixes, is exactly the shape this question wants, because everyone has lost a deploy to this once.

Answer: Attribute usage by path first: du -x --max-depth=2 /var/lib/docker | sort -h | tail or the equivalent for the container runtime root, then per-container overlay directories. Running processes map to containers via cgroup paths in /proc/PID/cgroup, and lsof +L1 catches containers holding deleted logs. Long term, per-directory quotas via filesystem projects or cgroup limits, plus log size caps, stop the whack-a-mole. The diagnostic split, static usage versus live file handles, is the reusable idea the question is really teaching.

Answer: Check the pipeline in order: ulimit -c in the process’s context, since 0 means none; the kernel’s kernel.core_pattern, which may pipe to systemd-coredump or systemd-coredump may be default on modern distros, storing via coredumpctl list; filesystem space and write permissions in the working directory; and setuid binaries, which are excluded by default for security. Then analyze with gdb program core or coredumpctl gdb. Naming the setuid exclusion and the pattern redirection shows you have actually chased a missing core before.

Answer: Trace it: strace -f -e trace=openat,stat cmd and read the sequence, or attach to a running daemon with -p. On a hardened box without ptrace rights, alternatives are ltrace for library calls, LD_PRELOAD of a small logging shim, or bpftrace one-liners on modern kernels. Complement with lsof -p PID after startup to see what it keeps open. The general principle to state: never guess paths from documentation when five seconds of tracing shows the truth, which is exactly the mindset scenario rounds reward. Evidence over documentation is the reflex Linux interview questions like this exist to build.

Answer: Fast wins first: truncate a runaway log in place with : > /var/log/huge.log, only after confirming the writer will keep appending rather than holding offset confusion, clean package caches with the distro’s clean command, vacuum the journal with journalctl --vacuum-size=200M, and clear old crash and tmp files with bounded find commands. Do not delete blindly under /var/lib for databases or container storage. Then schedule the real fix: find the growth source, set rotation caps, and alert on the filesystem. Saying what you refuse to touch under pressure is part of the correct answer. Knowing what not to delete is the judgment layer of Linux interview questions under time pressure.