Linux and Shell Interview Questions With Model Answers

I split it into three groups of three: owner rwx (7), group r-x (5), others --- (0). So the owner can read, write and run it, the group can read and run it, and everyone else has no access. The number is the sum per group: read is 4, write is 2, execute is 1. For a directory, x means "can enter and reach files inside" and r means "can list names". I always check a mode with stat -c '%a %A', because it shows both forms.

Execute on a directory is the "search" permission: you can reach things inside by name. Read lets you list the names. In my lab, as an unprivileged user, a 644 directory let me ls the names but cat dir/file failed with Permission denied. A 711 directory was the opposite: I could not list it, but I could read a file when I knew its name. The usual good setup is 755 for shared directories and 700 for private ones.

umask is a set of bits that are removed from the default mode of new files (666) and directories (777). With 027, new files get 640 and new directories get 750; I verified that: -rw-r----- and drwxr-x---. It is set per process and inherited by children, so a service's umask comes from its parent or its unit file. A default of 022 gives 644 and 755. I use 077 when a script creates secrets, and I put it in a subshell so it does not leak.

Setuid on an executable makes it run with the file owner's user id instead of the caller's. passwd is 4755 and owned by root, so you can change your own password, which needs a write to a root-owned file. The danger is that any bug in a setuid-root program becomes a root exploit, and a setuid shell script is even worse, so Linux ignores setuid on scripts. I keep the list of setuid files small: I would audit with find / -xdev -perm -4000 -type f (I did not run that whole-disk search in the lab). Setgid on a directory is different and useful: new files inherit the directory's group, which helps shared project folders. I did show the s in drwxr-sr-x after chmod g+s.

On a directory, the sticky bit means you can delete or rename only the files you own, even if the directory is writable by everyone. /tmp is 1777 (drwxrwxrwt). I tested it: an unprivileged user got Operation not permitted removing a root-owned file from a 1777 directory, and the same rm worked after I removed the sticky bit. The reason is that deleting a name is a write to the directory, not to the file, so the extra rule is needed.

First, the file is not executable: chmod +x, or run it as bash script. I saw exit status 126 for this, as opposed to 127 for "command not found". Second, a directory in the path has no x bit for me. Third, the file system is mounted noexec (common on /tmp in hardened systems; I did not test it). A fourth: the shebang points to an interpreter that is missing or not executable, which gives a confusing bad interpreter message. I start with ls -l, then namei -l path, which prints the mode of every directory in the path.

That 777 gives everyone, including every service on the machine, the right to change the file, so it hides the real problem. The real question is who needs access. If it is one service user, I use chown service:service and 750 or 640. If a team needs it, I create a group, set chown :team, use g+rwX, and set setgid on the directory so new files get the group. I use X (capital) in chmod -R so directories get execute but plain files do not; I checked that chmod -R a+X left a plain file at 644.

A hard link is a second name for the same inode, so the data stays until the last name is removed. A symbolic link is a small file that stores a path. In my lab, ln orig.txt hard.txt gave both names the same inode number (3006507) with link count 2, and ln -s made a separate file. After rm orig.txt, cat hard.txt still printed data, and cat soft.txt failed with No such file or directory (a dangling link). Hard links cannot cross file systems or point to directories; symlinks can do both.

SIGTERM (15) is a polite request. The process can catch it, finish its work, close files and exit; my test script printed got TERM, cleaning and exited 0. SIGKILL (9) cannot be caught or ignored, the kernel just removes the process, so there is no cleanup: temp files stay, locks stay, child processes may be orphaned. I always send SIGTERM first, wait a few seconds, and use kill -9 only if it does not exit. systemd and Kubernetes do the same: term, grace period, kill.

0 is success; 1 is a general failure; 2 usually means wrong usage (ls /nonexistent gave 2 in my lab, and grep uses 2 for errors, with 1 meaning "no match"). 126 means the file was found but cannot be executed; 127 means command not found. Anything above 128 is 128 plus a signal number: 137 is SIGKILL and 143 is SIGTERM. I reproduced 137 and 143 with kill -9 and kill. Exit codes are one byte, so exit 300 returns 44.

A zombie is a process that has finished but whose parent has not yet called wait to read its exit status, so a small entry stays in the process table. It shows Z in ps. I made one in the lab with a parent that did not wait: STAT was Z. It uses no CPU or memory, only a PID slot, so a few are harmless but thousands can exhaust PIDs. You cannot kill it, because it is already dead. The fix is to make the parent reap it (fix the bug, or send SIGCHLD), or stop the parent, after which init adopts and reaps it.

The process with PID 1 has two special jobs: it adopts orphans and must reap them, and the kernel does not apply default signal actions to it, so if it has no handler, SIGTERM is ignored. A Node or Python app run as PID 1 may not reap zombies or react to docker stop, which then waits 10 seconds and sends SIGKILL. The fixes are a tiny init (docker run --init, tini) and handling SIGTERM in the app. I did not run containers for this lesson; this comes from memory and experience.

When the terminal closes, the shell sends SIGHUP to its jobs and they usually die. Options: nohup cmd > out.log 2>&1 &, which makes the process ignore SIGHUP and sends output to a file; disown to remove a running job from the shell's list; tmux or screen to keep a whole session alive; or, properly, a systemd service. For anything that should survive reboots and restart on failure, I use a service, not nohup. I did not test logout behaviour in the sandbox (no real terminal), so this answer is from memory and experience.

Yes, redirections are processed left to right. 2>&1 means "point stderr at where stdout points right now". In cmd > out.txt 2>&1 stdout goes to the file first, so stderr follows it. In cmd 2>&1 > out.txt stderr copies the terminal first, so errors still print on screen while the file stays empty. I ran both with ls /nonexistent: the first file held the error, the second was empty. In bash, &> file is the short form. In a cron job this matters because the mail or log you expect will not contain the errors.

The > is performed by my shell before sudo is even started, so the file is opened with my permissions. sudo only elevates echo. The fix is to elevate the writer: echo x | sudo tee /etc/file >/dev/null (add -a to append), or sudo sh -c 'echo x > /etc/file'. I ran the tee form in the lab and it wrote the file, but I was root, so the failing case is not run here.

xargs splits on whitespace and treats quotes and backslashes specially, so a file named a b.txt becomes two arguments. In my lab it printed rm: cannot remove 'a' and rm: cannot remove 'b.txt'. The safe form is NUL-separated: find . -maxdepth 1 -name '*.txt' -print0 | xargs -0 rm. I also add -r (GNU) so xargs does nothing when the input is empty; without it echo -n | xargs echo run still printed run. -n2 groups arguments in twos, -P4 runs four at a time. For simple deletes, find ... -delete has no pipe at all.

grep to find lines: grep -E '" (4|5)[0-9]{2} ' access.log found the 4 error lines. sed to edit text as a stream: sed -i.bak 's/^port=.*/port=8080/' conf.ini. awk to work with columns and totals: awk '$11 > 1 {print $7, $11}' printed the slow requests. A practical rule is that if I can say it as "lines that match", it is grep; "change this text", sed; "for each line, do something with field N", awk. For big jobs or nested data (JSON), I use jq or a real language instead.

Extract the field, sort so equal values are neighbours, count, and sort the counts: awk '{print $9}' access.log | sort | uniq -c | sort -rn. On my sample log it printed 4 200, 2 500, 1 404, 1 401. For IPs I replace $9 with $1 and add | head. The sort before uniq -c is needed because uniq only collapses adjacent lines. I always check which field is which with head -1 first, because quoted request strings contain spaces.

\; runs the command once per file; + batches many files into one call. On my four-file tree, \; produced 4 lines of output and + produced 1, which means one process instead of four. For thousands of files + is far faster. -delete is handy, but the order of arguments matters: find . -delete -name '*.log' would delete everything, because tests are evaluated left to right. I put -delete last and run the same command with -print first to see what it would remove.

GNU sed (Linux) accepts -i with an optional suffix attached (-i.bak) or none. BSD sed (macOS) requires a suffix argument after -i, so sed -i 's/a/b/' file fails or misreads the next argument; the portable form is sed -i.bak 's/a/b/' file && rm file.bak. I only ran GNU sed 4.9, so the macOS behaviour is not run, and I would test on a Mac. The same kind of trap exists for date, xargs -r and readlink -f. For portability I can use perl -pi -e or write the edit in Python.

Unquoted $var is split on spaces and expanded as a glob. With f="my file.txt", ls -l $f looks for two files, my and file.txt; I ran it and got two errors. With pat="*.dat", echo $pat printed the matching file names and echo "$pat" printed the star. The worst case is rm -rf $dir/ with an empty dir, which becomes rm -rf /; I only echoed that command, never ran it. So I quote every expansion, use "${dir:?}" to stop on empty values, and run shellcheck, which flags it as SC2086.

[ is a normal command (an alias of test), so the shell splits and expands its arguments first. [[ ]] is bash syntax, so it parses its own words. The practical differences, all shown in my lab: with an empty $v, [ $v = x ] fails with unary operator expected (exit 2) while [[ $v = x ]] returns 1 quietly; [[ abc == a* ]] does pattern matching; [[ ]] supports &&, || and =~ regex. The cost is portability: [[ ]] is not POSIX, so in a #!/bin/sh script on Debian (where sh is dash) I use [ ] with quotes.

-e exits on a failed command, -u treats unset variables as errors, and -o pipefail makes a pipeline fail if any stage fails. The surprises I proved: -e is ignored in if conditions and &&/|| lists (false && echo x did not stop the script); local y=$(false) does not fail because local returns 0; ((i=0)) returns status 1 and stops the script; and pipefail can fail a harmless pipe, for example grep nomatch file | wc -l exits 1 because grep found nothing, which printed 0 and then stopped my script. I use it as a safety net but still check important commands explicitly, and I use trap ... ERR or EXIT for cleanup.

The loop was on the right side of a pipe, and each part of a pipeline runs in a subshell, so the increments happened in a copy. My test printed n=0 with printf ... | while read, and n=2 when I wrote while read ...; done < <(printf ...). Other fixes: redirect from a file (done < file) or use shopt -s lastpipe (non-interactive bash). I also use read -r so backslashes are kept and IFS= so leading spaces are kept.

I make a key pair; the private key stays with me, and the public key goes into ~/.ssh/authorized_keys on the server. At login the server sends a challenge, and my client proves it holds the private key by signing it, without sending the key. Permissions matter: the private key must be 600 (my lab test printed WARNING: UNPROTECTED PRIVATE KEY FILE! for 644), ~/.ssh should be 700, and authorized_keys not writable by others, otherwise sshd with StrictModes refuses it (lesson 5 showed that login failing and then working after chmod 700). I also check the server host key fingerprint the first time, and I protect the key with a passphrase plus ssh-agent.

It opens port 9000 on my machine. Anything I send to localhost:9000 travels through the encrypted SSH connection and is delivered to 127.0.0.1:8081 as seen from the server, which is the server's own localhost. It is how I reach a database or admin page that listens only on the server's loopback address. -R does the reverse (the server listens and sends traffic back to me) and -D makes a SOCKS proxy. I ran -L end to end in lesson 5 and reviewed, but did not run, -R and -D. Add -N if you only want the tunnel and no shell.

Cron is simple and everywhere; a systemd timer gives logs in the journal, Persistent=true catch-up after downtime, dependencies, and resource limits. For the cron failure, the usual cause is the environment: cron runs with a tiny PATH and none of my shell setup. My lab showed it: a normal shell had a long PATH including /opt/node22/bin, while env -i gave only system directories. Fixes: absolute paths, set PATH= at the top of the crontab, redirect output (>> /var/log/job.log 2>&1) so errors are not lost, and use flock to stop overlapping runs. I verified the environment effect, but I did not run a real cron daemon or a timer here.

A process still holds a deleted file open. rm removes the name, but the space is freed only when the last open handle closes. du adds up names; df asks the file system. In my lab: df showed 3.0M used and du -sh showed 0. lsof +L1 listed /tmp/lab-linux-c/mnt/big (deleted). To fix it I restart the process (or truncate the file with : > file before deleting in future). Other causes: files hidden under a mount point, and reserved blocks on ext4.

Check inodes with df -i. In my lab df -h said 0% used while df -i said 100%, and touch failed with exactly that message. Millions of small files (sessions, caches, mail queues) can use up all inodes. I find the directory with the most entries, delete or archive them, and fix the producer. Other causes: disk quotas, or I am looking at a different mount than the one that is full (df -h /path tells me).

Not necessarily. Linux uses spare RAM as page cache to speed up file reads and gives it back when programs need it. I read the available column, not free. On my lab VM, free was 13 GiB and available 15 GiB with 1.7 GiB in cache. Real memory pressure looks like: available near zero, swapping (si/so in vmstat), and OOM-kill lines in dmesg. I did not trigger an OOM kill in the lab, so that part comes from memory and the kernel docs I read for lesson 7, not from my own output.

It is the average number of tasks that are running, waiting for a CPU, or (on Linux) blocked on disk, over 1, 5 and 15 minutes. I compare it with the core count (nproc). On 4 cores, a load of 8 means about twice as much work as the CPUs can do, so tasks queue; on 16 cores it is half idle. I also read the trend: 1 min < 15 min means it is recovering. Since disk waits count, high load with low CPU use points to an I/O problem, so I look at wa in top and at iostat.

I ask what changed and when it started. Then I go resource by resource, checking utilisation, saturation and errors: uptime and top for CPU and load, free -h (available) and vmstat for memory and swapping, df -h, df -i and du for disk space, iostat -dx 1 for disk speed, ss and curl -w for the network, and finally the application logs with an awk | sort | uniq -c count of status codes. I narrow to machine versus application first, because a slow database query will not show up in any OS tool. I change one thing at a time, confirm the fix, and write down the cause. In my lab VM this routine would have flagged / at 97% with 1.3 GB left, before anything else.

The kernel can only remove a process when it is back in user mode. If the process is in uninterruptible sleep (D in ps), usually waiting for a disk or a hung network file system (NFS), the signal stays pending until the I/O returns. A zombie also cannot be killed because it is already dead. I confirm with ps -o pid,stat,wchan:20,cmd -p PID, then fix the cause: the storage or mount, not the process. I did not reproduce a D-state process in the sandbox; this is from memory and experience. Hung NFS mounts are the classic case, and umount -l or a reboot is sometimes the only way out.

Before running: bash -n script checks syntax, and shellcheck script finds quoting and logic traps (it flagged rm $1 and a for f in $(ls) loop on my sample file). While debugging: bash -x script prints each command after expansion, or set -x around the part I care about, with PS4='+ ${LINENO}: ' for line numbers. I also make scripts safe to re-run (idempotent), use trap cleanup EXIT, and test destructive steps with echo in front first, as I did for the rm -rf "$dir/" example.

Short questions, short answers. Practise saying each in one breath.

Ask a friend to read these, or time yourself. For each, the "good answer includes" list is what a strong candidate says in about two minutes. Score yourself: 2 points if you hit most items, 1 if half, 0 if you freeze.

1. "I deleted a 5 GB log but the disk is still 100%. What happened?" Good answer includes: a process holds the deleted file; df versus du; lsof +L1; restart or truncate; log rotation as the long-term fix.

2. "A deploy script works on my laptop but fails in cron." Good answer includes: tiny environment and PATH; absolute paths; redirecting stderr to a log; the working directory; flock; checking with env -i.

3. "Explain what this does: find /var/log -name '*.gz' -mtime +30 -print0 | xargs -0 rm." Good answer includes: finds compressed logs older than 30 days; NUL separators keep odd names safe; rm is destructive so run with -print or ls first; or use -delete; and be careful with the path.

4. "Why did this script keep running after cd failed?" Good answer includes: cd returns non-zero but the script ignored it (I saw still going in /tmp/lab-linux-c); use cd dir || exit 1 or set -e; quote the path; shellcheck warns (SC2164).

5. "Production server, load is 25 on 8 cores, CPU is only 10% busy." Good answer includes: Linux load counts tasks in D state; look at wa and iostat; check a hung NFS mount or a slow disk; ps for D processes; not a CPU problem.

6. "How do you reach a database that listens only on localhost of a remote server?" Good answer includes: ssh -L local:127.0.0.1:5432 host; the second address is from the server's point of view; -N for no shell; bastion with -J; never open the database to the internet.

Scoring: 10 to 12 is strong. 6 to 9 means re-read the lessons for the questions you missed. Below 6, do the Try-it lab above with a real shell instead of reading again.