Comprehensive knowledge of operating system concepts and practical administration across Linux, Unix, and Windows platforms. Core theoretical topics include processes and threads, process creation and termination, scheduling and context switching, synchronization and deadlock conditions, system calls, kernel versus user space, interrupt handling, memory management including virtual memory, paging and swapping, and input and output semantics including file descriptors. Practical administration and tooling expectations include file systems and permission models, user and group account management, common system utilities and commands such as grep, find, ps, and top, package management, service and process management, startup and boot processes, environment variables, shell and scripting basics, system monitoring, and performance tuning. Platform specific knowledge should cover Unix and Linux topics such as signals and signal handling, kernel modules, initialization and service management systems, and command line administration, as well as Windows topics such as the registry, service management, event logs, user account control, and graphical and command line administration tools. Security and infrastructure topics include basic system hardening, common misconfigurations, and an understanding of containerization and virtualization at the operating system level. Interview questions may probe conceptual explanations, platform comparisons, troubleshooting scenarios, or hands on problem solving.
HardTechnical
76 practiced
Describe virtual memory internals: page tables, Translation Lookaside Buffer (TLB), multi-level page table walks, demand paging, page faults, and common page replacement algorithm approximations (LRU, clock). Explain how hugepages and transparent hugepages affect TLB pressure and performance; when would you enable hugepages for database workloads and what trade-offs should you consider?
Sample Answer
**Overview — core concepts**- Virtual memory maps virtual addresses to physical frames via page tables; the CPU walks page tables to resolve virtual→physical mappings.- TLB caches recent translations to avoid costly walks; a TLB miss triggers a page-table walk (multi-level: PML4→PDPT→PD→PT on x86_64), which accesses multiple memory levels and stalls the CPU.- Demand paging: pages are loaded from disk (or zeroed) only when accessed; a page-fault causes the kernel to locate or allocate the page, possibly read from swap or backing store, then update page tables and TLB.**Page replacement approximations**- LRU: ideal but expensive to implement exactly in OS; tracks recency and evicts least-recently-used.- Clock (approximate LRU): circular buffer with a use-bit; evict pages by scanning and clearing use-bits—cheap and commonly used in kernels.**Performance implications**- TLB pressure: small pages mean more page table entries and more TLB misses for large working sets. Each TLB miss costs a page-table walk (multiple memory loads) plus possible kernel overhead.- Hugepages (e.g., 2MiB, 1GiB): reduce number of PTEs and increase TLB reach, lowering TLB miss rate and page-table walk overhead. Transparent HugePages (THP) attempts automatic promotion/compaction.**When to enable for databases**- Good candidates: large in-memory DBs (Postgres, Oracle, MySQL/InnoDB buffer pool) with stable, large working sets where reduced TLB misses yield measurable throughput/latency gains.- Prefer explicit hugepages (Linux hugetlbfs / vm.nr_hugepages) for predictable performance: they’re locked/pinned and not subject to compaction at runtime.- THP (vm.transparent_hugepage=always/madvise) is easier but can cause latency spikes during background compaction or on-demand promotion; use carefully and test.**Trade-offs / operational considerations**- Memory fragmentation and allocation failures: hugepages require contiguous physical memory; allocating them on busy systems can fail or trigger compaction.- Wasted memory/internal fragmentation: if many allocations are small, hugepages can waste RAM.- Reduced flexibility: hugetlb pages are pinned, not swappable—watch OOM risk.- Complexity: need sysctl tuning (vm.nr_hugepages, vm.max_map_count), NUMA-aware placement, hugepage alignment, and application support (e.g., madvise/MAP_HUGETLB).- Monitoring: track TLB miss rates, major/minor faults, page fault latencies, and throughput before/after change.Example commands/config:- Reserve explicit hugepages: echo <N> > /proc/sys/vm/nr_hugepages- Enable THP: echo madvise > /sys/kernel/mm/transparent_hugepage/enabled- For DBs, prefer backing with hugetlbfs or MAP_HUGETLB and test under production-like load; measure latency tail and throughput to validate benefits.
HardTechnical
64 practiced
A high-performance network server displays high irq and softirq CPU usage concentrated on a few cores, degrading throughput. Explain how interrupts are delivered and processed, how to analyze irq/softirq distribution (for example using /proc/interrupts, ethtool -S, and irqbalance), and propose tuning strategies such as IRQ affinity, device queue tuning (RPS/XPS), and CPU isolation to improve throughput and reduce latency.
Sample Answer
**Interrupt delivery & processing (brief)** - NIC signals IRQ to CPU via PIC/APIC/MSI-X; MSI-X lets the NIC assign many vectors. - Kernel handles hardware IRQ (hard IRQ context) and quickly schedules work on softirq (NET_RX, NET_TX) processed on the interrupted CPU or by ksoftirqd/NAPI poll loops. High per-core irq/softirq concentration causes cache thrashing and drops.**How to analyze distribution** - Check counts per CPU:
bash
cat /proc/interrupts
- Per-NIC stats:
bash
ethtool -S eth0
- Watch softirq:
bash
watch -n1 cat /proc/softirqs
- Check irqbalancer status (may move IRQs dynamically):
bash
systemctl status irqbalance
**Tuning strategies (practical actions)**1) IRQ affinity (pin vectors to CPUs) - Stop irqbalance while testing:
bash
systemctl stop irqbalance
- Set affinity mask for vector (hex mask per /proc/irq/<N>/smp_affinity):
bash
echo 0f > /proc/irq/42/smp_affinity # CPUs 0-3
- For MSI-X, map each queue/vector to a CPU core to align RX queue -> core where app threads run.2) Device queue tuning (RSS/RPS/XPS, ring sizes) - Set NIC RSS/RSS hash offloads via driver/ethtool (enable multiple queues):
bash
ethtool -L eth0 combined 8 # adjust rings/queues
- Set RPS (software steering for packets to other CPUs) per rx queue:
3) CPU isolation and affinity for application threads - Isolate CPUs in kernel cmdline (isolcpus or nohz_full) and pin IRQs and your network-processing threads to the remaining CPUs via taskset/cgroup CPU affinity to avoid interference.4) Use driver/NAPI tuning - Increase NAPI budget or adjust rx/tx coalescing responsibly:
bash
ethtool -C eth0 rx-usecs 50 tx-usecs 50
5) Automate & monitor; re-enable irqbalance with policy or use tuned scripts - Use irqbalance’s --oneshot or custom rules if dynamic movement needed. Test with representative workload and monitor latency/throughput.**Trade-offs & validation** - Pinning improves cache locality and latency but reduces scheduler flexibility. RPS/XPS use more CPU cycles but improve parallelism for many flows. Always benchmark (iperf/netperf + perf/top -H, tcpdump) and iterate.
EasyTechnical
76 practiced
Describe how you would use common Linux utilities to diagnose a slow server: ps, top/htop, free, vmstat, iostat, df, du, lsof and grep. For each utility give a short example command and explain which symptom it helps identify (high CPU, memory pressure, I/O wait, disk full, open file handles, etc.). Also mention when a tool is preferable in production because of low overhead.
Sample Answer
**Overview (Systems Administrator voice)** I’d start with lightweight sampling, then drill down. Below are utilities, an example command, what symptom they reveal, and production-overhead notes.**ps**
bash
ps aux --sort=-%cpu | head -n 10
Finds processes with high CPU or memory usage (one-shot snapshot). Low overhead.**top / htop**
bash
top -b -n 1
htop
Interactive view of CPU, load, per-thread usage. Use non-interactive top for scripts; htop is great for live debugging but higher overhead.**free**
bash
free -m
Shows memory, swap usage and available cache — identifies memory pressure and swap thrashing. Very low overhead.**vmstat**
bash
vmstat 1 5
Reports CPU, memory, swap, IO wait trends — good for spotting sustained I/O wait or swapping. Low overhead; ideal in production for short sampling.**iostat**
bash
iostat -x 1 3
Shows per-device I/O utilization and await — identifies disk bottlenecks and high I/O wait. Low-to-moderate overhead, safe for short intervals.**df**
bash
df -h
Checks filesystem capacity to spot full disks/partitions. Very low overhead.**du**
bash
du -sh /var/* | sort -h
Finds which directories consume space (resolving df “full” symptoms). Use with care on large trees; can be expensive.**lsof**
bash
lsof +L1 # files deleted but still open
lsof -p 1234 # open files by PID
Identifies open file handles, deleted-but-held files causing disk not to free. lsof can be heavy on busy systems; run targeted queries.**grep**
Filters output to find relevant lines; negligible overhead.Production notes: prefer non-interactive, short-interval vmstat/iostat/free/ps/df for low overhead. Reserve htop, full du, and broad lsof for controlled troubleshooting windows.
MediumTechnical
69 practiced
You are given a Linux server where a legacy daemon exits with errno 13 (Permission denied) when attempting to write to a socket. Describe how you would use strace to trace system calls and locate the failing syscall. Include the exact strace flags you would use to follow forks, capture networking-related syscalls, and reduce noise. Also mention the equivalent tools/approach for tracing syscall-like behavior on Windows.
Sample Answer
**Approach (high level)**Attach strace to the daemon and capture only networking/syscall families while following child processes. Filter output to the failing syscall (errno 13) and correlate with UID/GID and file/socket permissions.**Exact strace command I'd use**
bash
# attach by PID:
sudo strace -ff -e trace=network,desc -s 256 -o /tmp/strace-daemon.log -p <PID>
# or run the daemon and log:
sudo strace -ff -e trace=socket,bind,connect,accept,sendto,recvfrom,sendmsg,recvmsg,setsockopt,getsockopt -s 256 -o /tmp/strace-daemon.log <command>
Flags explained- -f : follow forks/threads so child processes are traced- -ff : write each traced process to a separate file (adds PID suffix)- -e trace=... : limit to networking/syscall names to reduce noise (use specific names if needed)- -s 256 : capture more of string arguments (useful for socket paths)- -o : write to file for offline searchingHow to locate the failing syscall- grep "Permission denied" or "EACCES" in /tmp/strace-daemon.log* to find the exact syscall and PID- inspect preceding calls (socket, bind, connect, open, stat, access, getsockopt) to determine why permission denied (e.g., attempting to bind privileged port <1024, UNIX socket path permissions, SELinux deny)- check process UID/GID, effective capabilities, and file/socket permissions; confirm with ls -l, getfacl, and cat /proc/<PID>/status for CapEffAdditional tips- add -ttt for epoch timestamps to correlate logs with system logs- use -k (if available) to follow kernel stacks or use perf/ebpf for deeper tracing- check /proc/<PID>/fd and use ss/netstat to inspect socket stateWindows equivalents- Procmon (Sysinternals Process Monitor): filter by PID and Operation (TCP Connect, CreateFile, Access) to see ACCESS DENIED events- TcpView or Network Monitor / Wireshark for network ops- API Monitor or WinDbg for syscall-like tracing and call stacks (useful for higher-level Win32 API failures)
MediumTechnical
58 practiced
On a RHEL/CentOS server, Apache is blocked from accessing a directory and you see AVC denials in /var/log/audit/audit.log. Explain how SELinux enforces access controls, how to interpret AVC messages, and the safe steps to create a minimal policy to allow the access (using audit2allow). Describe alternatives to permanently changing enforcement mode and how AppArmor on Ubuntu provides similar protection.
Sample Answer
**How SELinux enforces access controls**- SELinux implements Mandatory Access Control: every process and object has a context (user:role:type:range). Decisions are made by the policy, not by Unix UID/GID. In RHEL, httpd runs in type httpd_t and files must have types like httpd_sys_content_t to allow read.**Interpreting AVC messages**- AVC denials in /var/log/audit/audit.log show what was denied. Example snippet:
5. Test functionality, then monitor for regressions. Remove module if problems: `semodule -r myhttpd`.**Safer alternatives (avoid blanket changes)**- Use correct file context:
bash
semanage fcontext -a -t httpd_sys_content_t '/var/www/secret(/.*)?'
restorecon -Rv /var/www/secret
- Toggle booleans (persistent) instead of global permissive:
bash
getsebool -a | grep httpd
setsebool -P httpd_enable_homedirs on
- Temporary testing without policy change:
bash
setenforce 0 # temporary, not recommended in production
setenforce 1
- Per-domain permissive (less risk than global):
bash
semanage permissive -a httpd_t
semanage permissive -d httpd_t
**AppArmor on Ubuntu**- AppArmor is path-based profiles attached to programs (e.g., /usr/sbin/apache2). Similar protections: logs denials in syslog, tools to create policy from logs: `aa-logprof`. You can switch a profile to complain mode (`aa-complain /usr/sbin/apache2`) to collect denials, then `aa-enforce` once safe. AppArmor is simpler to use for path-specific cases but less fine-grained than SELinux type enforcement.
Unlock Full Question Bank
Get access to hundreds of Operating System Fundamentals interview questions and detailed answers.
