Operating System Fundamentals Questions

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.

HardSystem Design

69 practiced

Design a highly-available architecture for a stateful service on Linux that requires automatic failover with minimal downtime. Discuss how you would use systemd service units (and watchdog), cluster managers (Pacemaker/Corosync), keepalived/VRRP, shared storage solutions (DRBD/NFS), split-brain prevention, fencing/stonith, and health checks. Explain how configuration and deployment updates should be handled safely.

Sample Answer

**Design overview** Run an active/passive cluster across two (or more) Linux hosts with local service managed by systemd, automatic failover by Pacemaker/Corosync, virtual IP via keepalived/VRRP, synchronous block replication with DRBD, and fencing/STONITH to prevent split-brain. NFS only for read-shared artifacts; production state lives on DRBD primary.

**Components & responsibilities**- systemd service unit + watchdog: keep the application supervised locally; use WatchdogSec and Type=notify or simple with sd_notify to allow fast local restarts and signal health to cluster layer.- Pacemaker/Corosync: orchestrates resource promotion/demotion (DRBD role, filesystem mount, systemd service start/stop) and handles fencing hooks.- keepalived/VRRP: advertise a floating VIP to clients; controlled by Pacemaker (resource agent) to avoid races.- DRBD: synchronous replication (protocol C) for block-level mirroring; configure automatic split-brain recovery disabled — let cluster manage promotion.- Filesystem: use a clustered-aware filesystem (e.g., ext4/XFS on promoted node) or GFS2 if multi-writer required.- Fencing/STONITH: mandatory — integrate IPMI, iLO, or power-controller agents into Pacemaker to forcibly power-off failed nodes before promotion.- Split-brain prevention: strict quorum rules, quorum device or tie-breaker, and DRBD fencing settings; avoid split-brain by requiring two-factor promotion (Corosync quorum + STONITH success).- Health checks: multi-level probes — systemd watchdog, application liveness/readiness endpoints, DRBD status, and periodic Pacemaker resource checks; escalate failures (local restart -> relocate -> STONITH if unresponsive).

**Failover flow**1. Local failure detected by systemd watchdog or app probe.2. Pacemaker notices resource failure; attempts local recovery (systemd restart).3. If recovery fails, Pacemaker demotes DRBD, unmounts filesystem, moves VIP via keepalived resource to secondary, promotes DRBD primary there, mounts FS, starts systemd service.4. STONITH executed if node is reachable but misbehaving.

**Configuration & deployment updates**- Use configuration management (Ansible/Chef) and immutable artifacts (container images or versioned packages).- Staged rollout: test in canary cluster, then rolling updates node-by-node. Before updating a node: - Promote alternate node, verify health, run update, then fail back if desired.- For config changes to cluster-managed resources: update pacemaker resource agents via transactions (crm shell with batch mode) to avoid transient inconsistent state.- DRBD metadata and filesystem upgrades: test on clone; use maintenance mode in Pacemaker to prevent automatic failover during planned ops.- Automated pre-checks: validate quorum, DRBD sync-state, STONITH reachability before changes.- Backup and rollback: snapshot DRBD metadata and filesystem, keep DB/application backups.

**Trade-offs & notes**- Synchronous DRBD adds write latency; acceptable for strong consistency. For higher performance use async replication + app-level reconciliation.- Keepalived alone isn't cluster-aware—use Pacemaker to avoid split VIP ownership.- STONITH is non-negotiable for stateful services; skipping it risks data corruption.

This design provides sub-second detection via systemd/pacemaker health checks, controlled automated failover, and safe, testable update paths that minimize downtime while protecting data integrity.

HardTechnical

59 practiced

Explain in detail what happens during a context switch from user space into the kernel and back (registers saved/restored, CR3/TLB behavior, stack transitions). Quantify the types of overhead involved and propose specific strategies to reduce context-switch and syscall overhead for a latency-sensitive service (for example, reduce syscalls with batching, use VDSO, io_uring, CPU affinity, or hugepages).

Sample Answer

**Brief overview of the transition**- User → kernel: a syscall instruction (syscall/sysenter/int 0x80) triggers a controlled trap. CPU switches CPL (ring 3 → ring 0), loads kernel CS/SS, switches stack pointer to the process’s kernel stack (from TSS or via per-thread kernel stack pointer), saves user RIP/CS/FLAGS and some general-purpose registers into kernel context or on stack, and transfers control to the syscall entry handler.- Kernel → user: syscall handler prepares return values, restores saved registers, switches stack pointer back to the user stack, and executes a return instruction (sysret/iret) to resume user execution.

**Registers / state saved & restored**- Automatically saved by CPU: RIP, CS, RFLAGS (on interrupt/iret) or limited on fast syscall path.- Kernel saves: caller-saved GPRs used by handler, callee-saved if preempted, FS/GS base (if changed), SIMD/AVX state only on demand (lazy FPU save/restore or full XSAVE/XSAVEOPT on context switch).- Control registers: CR3 (page-table base) is updated only on process (address-space) switch; CR4/CR0 rarely change.

**CR3 / TLB behavior**- Changing CR3 flushes TLB entries for the outgoing address space (unless PCID enabled). Without PCID each CR3 reload incurs TLB flush cost causing many page-walks = memory stalls.- With PCID, TLB entries can be tagged per address-space avoiding flush on CR3 switch if OS preserves PCIDs; still some management overhead.- I/O and interrupt-induced context switches may also cause pipeline and branch-target buffer thrashing.

**Stack transitions**- CPU uses kernel stack pointer from TSS or model-specific mechanism; kernel must ensure per-thread kernel stacks are mapped and non-overflowing.- Nested traps use IST entries or push further frames; careful handling needed for small kernel stacks.

**Quantified overheads (order-of-magnitude)**- Simple syscall (VDSO path): ~20–100 cycles- Traditional syscall trap + kernel handling: ~200–1000 cycles depending on handler cost and cache/TLB state- Full context switch (scheduling to another process, CR3 switch, FPU save/restore): thousands of cycles (1–10 µs typical on modern x86)- TLB refill/page walk: ~100–300 cycles per miss; many misses amplify switch cost- Cache-effects and pipeline flush: dozens to hundreds of cycles

**Strategies to reduce syscall / context-switch latency**- Avoid kernel transitions: - Use VDSO for fast time and gettimeofday-like calls (no trap). - Batch syscalls: aggregate data and do fewer transitions. - Use shared memory + user-level protocols to avoid syscalls for frequent ops.- Asynchronous / kernel-side batching: - Use io_uring (submission/completion rings) to submit many I/O ops with few syscalls and avoid per-op context switches.- Kernel-bypass: - DPDK, AF_XDP for networking to avoid kernel stack and copies.- Reduce address-space switches: - Use threads instead of processes to reuse same CR3 (no TLB flush). - Enable and use PCID to avoid TLB flushes on CR3 changes.- CPU/memory affinity: - Pin threads to CPUs (sched_setaffinity), lock memory (mlock/hugepages) to reduce cache/TLB misses and page faults.- Hugepages: - Use hugepages for large working sets to reduce TLB pressure and page-walk costs.- Scheduler / preemption tuning: - Use SCHED_FIFO / real-time priorities for latency-sensitive threads; reduce involuntary preemption. - Increase kernel tunables to reduce scheduler wake latency (e.g., sysctl tickless, timer granularity).- Reduce locking and syscalls in hot path: - Use user-space lock-free queues, per-core data structures, and minimize blocking syscalls.- FPU/AVX handling: - Avoid unnecessary FPU state flips by keeping affinity and using worker threads that need SIMD exclusively.

**Trade-offs / operational notes**- Kernel-bypass reduces latency but loses kernel services (security, manageability). Use only when justified.- Pinning and hugepages reduce jitter but hurt overall scheduler flexibility and NUMA balance.- io_uring + batching is high value: preserves kernel safety, reduces syscalls dramatically, and is practical for many services.

This explanation targets practical levers a systems engineer can apply: measure current syscall/context-switch costs with perf/latency tools, prioritize low-effort wins (VDSO, batching, io_uring), then consider kernel-bypass and affinity/hugepage tuning for extreme low-latency needs.

EasyTechnical

63 practiced

You need to find processes consuming more than 80% CPU, determine which files under /var/log were modified in the last 7 days, and list any processes listening on TCP ports above 1024 on a Linux server. Provide a sequence of commands (using grep, find, ps, top/htop, ss/lsof) to accomplish these tasks and briefly explain why you chose each command and any common pitfalls (e.g., different ps formats or hidden processes).

Sample Answer

**Find processes consuming >80% CPU**

1) Use ps (snapshot):

bash

ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | awk '$4>80 {print}'

Why: ps gives a reliable snapshot and sortable CPU. Pitfalls: different ps implementations may show %CPU differently; snapshot misses short spikes. For interactive monitoring use:

bash

top -b -n1 | head -n20
# or htop (interactive) to inspect threads and kill if needed

**Files under /var/log modified in last 7 days**

bash

find /var/log -type f -mtime -7 -ls

Why: find is efficient for mtime. Pitfalls: log rotation may move files; -mtime uses 24h units (use -mtime -7 for <7 days). Use -iname to include compressed logs.

**Processes listening on TCP ports >1024**

bash

ss -tlnp '( sport > 1024 )'
# or
lsof -iTCP -sTCP:LISTEN -Pn | awk '$9+0>1024 || $9 ~ /:([0-9]+)$/ && substr($9, index($9,":")+1)+0>1024'

Why: ss is modern and fast; lsof shows process -> file mapping. Pitfalls: ss filters vary by version; need root to see other users' processes. Hidden processes (via rootkits) require integrity checks and kernel-level inspection.

MediumTechnical

63 practiced

Explain the Completely Fair Scheduler (CFS) in Linux and how it differs from real-time scheduling classes such as SCHED_FIFO and SCHED_RR. How do niceness and ionice affect scheduling, and what commands and precautions would you use to safely promote a process to real-time priority on a production server?

Sample Answer

**Overview of CFS**- CFS (Completely Fair Scheduler) is Linux’s default SCHED_NORMAL class. It models fairness by tracking each runnable thread’s virtual runtime (vruntime) and runs the task with smallest vruntime using a red‑black tree. CFS aims to give proportional CPU share based on weight (derived from niceness). It is preemptive and supports load‑balancing across CPUs.

**How it differs from real‑time classes**- SCHED_FIFO and SCHED_RR are real‑time (RT) scheduling classes with strict priority ordering above CFS. Any runnable RT task will preempt CFS tasks. - SCHED_FIFO: non‑timesliced, runs until blocks or yields. - SCHED_RR: timesliced among same priority RT tasks.- RT tasks can monopolize CPU if not constrained — useful for low‑latency but dangerous on multi‑user/production systems.

**Niceness and ionice**- nice (and setpriority) adjusts a process’s niceness (-20..19). CFS maps niceness to weight: lower nice → higher weight → smaller vruntime increment → more CPU share. Niceness does NOT affect RT classes. - Example: nice -n 10 ./process- ionice sets I/O scheduling class/priority for processes (uses CFQ/blk-iosched or io‑cgroups); it affects block I/O dispatch priority but not CPU scheduling directly. - Example: ionice -c2 -n7 -p PID (best‑effort class, low priority)

**Commands to promote to real‑time (and safer alternatives)**- Direct promotion (dangerous): - chrt -f 99 ./binary # SCHED_FIFO priority 99 - chrt -r 50 -p PID # SCHED_RR for existing PID- Safer approaches and precautions: - Use lower RT priority (not 99). Start with modest priority (e.g., 10–20). - Use cgroups v2 to constrain RT runtime: - echo 950000 > /sys/fs/cgroup/<cg>/cpu.max # runtime_us (e.g., 950ms) - echo 1000000 > /sys/fs/cgroup/<cg>/cpu.period - Use systemd transient service to control limits: - systemd-run --unit=myrt --slice=machine.slice --property=CPUQuota=50% chrt -f 20 /usr/bin/worker - Test in staging and during maintenance windows. Monitor CPU, load, latencies, and run top/htop (SHOW RT), ps -o pid,rtprio,pri,ni,cmd. - Limit file descriptors, use ulimit, and ensure watchdogs/oom_killer settings are acceptable. - Avoid promoting on multi‑tenant hosts; prefer dedicated hosts or affinity (taskset/cpuset) to isolate RT thread: - taskset -c 4 chrt -f 20 ./binary - echo 4 > /sys/fs/cgroup/<cg>/cpuset.cpus

**Monitoring and rollback**- Watch for system responsiveness, process preemption, and throttling (dmesg may show RT throttling).- If issues, kill or lower RT priority (chrt -p -o PID or renice), remove cgroup, revert systemd property.

Why this matters: use RT only when latency guarantees outweigh global fairness. Prefer niceness + io‑priority + cpuset/cgroups before escalating to SCHED_FIFO/RR, and always constrain RT with quotas and testing on production.

MediumTechnical

81 practiced

Explain how to load, unload, and manage kernel modules on Linux, including how to inspect module dependencies, view parameters, and persist module loading across reboots. If a module fails to load with 'invalid module format' or causes an oops, describe the troubleshooting steps you would take (checking kernel version mismatch, modinfo, dmesg, and rebuilding the module).

Unlock Full Question Bank

Get access to hundreds of Operating System Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.