Linux Interview Questions: Complete Guide with Answers

Linux: A free, open-source, Unix-like operating system kernel created by Linus Torvalds in 1991. Linux distributions combine the kernel with GNU utilities and other software.

Unix: A family of multitasking, multiuser computer operating systems originally developed at AT&T Bell Labs in the 1970s.

Key Differences:

Why this matters: Understanding these differences helps in making informed decisions about which OS to use for specific workloads, understanding compatibility issues, and troubleshooting cross-platform problems.

The Linux Filesystem Hierarchy Standard (FHS) defines the directory structure and directory contents. Here are the key directories and their purposes:

Practical Examples:

• /etc/: Contains system-wide configuration files. For example, /etc/passwd stores user information, /etc/fstab defines filesystem mounts.
• /var/log/: Where system logs are stored. /var/log/syslog contains general system messages, /var/log/auth.log stores authentication logs.
• /proc/: A virtual filesystem providing process and kernel information. /proc/cpuinfo shows CPU details, /proc/meminfo shows memory information.
• /dev/: Contains device files. /dev/sda represents the first hard disk, /dev/null is a null device that discards data.

Why this matters: Knowing the filesystem hierarchy is essential for:

• Troubleshooting: You know where to look for logs and configuration files
• Security: You understand which directories need strict permissions
• Application deployment: You know where to install applications and store data
• System maintenance: You understand what can be safely cleaned up

Inodes (Index Nodes) are data structures in Unix/Linux filesystems that store metadata about files and directories, except the filename and the actual data.

What information is stored in an inode:

• File type (regular file, directory, symbolic link, device file)
• Permissions (read, write, execute for owner, group, others)
• Owner and group IDs
• File size in bytes
• Timestamps (creation, modification, access)
• Link count (number of hard links to the inode)
• Pointers to data blocks (direct, indirect, double indirect)
• Device ID (for device files)

Visual Representation:

Key Commands for Working with Inodes:

Common Scenarios and Solutions:

1. "No space left on device" but df shows free space:
   This indicates inode exhaustion. Use df -i to check inode usage.
   # Solution: Find and clean up small files # Find directories with many files find /path -type f -name "*.log" -size +0c | xargs rm # Or use find to delete old small files find /path -type f -size -1k -mtime +30 -delete
2. Hard links vs Symbolic links:
   Hard links share the same inode, symbolic links have their own inode.
   # Create hard link (same inode) ln original.txt hardlink.txt ls -i original.txt hardlink.txt # Same inode number # Create symbolic link (different inode) ln -s original.txt symlink.txt ls -i original.txt symlink.txt # Different inode numbers
3. Filesystem differences:
   EXT4 vs XFS vs BTRFS handle inodes differently:
   • EXT4: Fixed number of inodes at format time
   • XFS: Dynamic inode allocation
   • BTRFS: No traditional inodes, uses B-trees

Why this matters:

• Troubleshooting: Understanding inodes helps diagnose "disk full" errors
• Performance: Inode-heavy operations affect filesystem performance
• Storage planning: Choosing appropriate filesystem for workload
• File recovery: Understanding how files are stored and referenced

Process: An independent execution unit with its own memory space, resources, and state. Each process has its own address space, file descriptors, and security context.

Thread: A lightweight unit of execution within a process. Threads share the same memory space and resources as their parent process but have their own stack and register state.

Visual Representation:

Practical Examples in Linux:

When to use processes vs threads:

• Use Processes when:
  • You need strong isolation between tasks
  • Tasks don't need to share much data
  • Security is critical (different privileges needed)
  • You want to leverage multiple CPUs effectively
• Use Threads when:
  • Tasks need to share data frequently
  • You need lightweight concurrency
  • Tasks are I/O bound and waiting often
  • You need to create many concurrent tasks

Common Interview Scenarios:

1. "Why does my application crash when one thread fails?"
   Because threads share memory space. A thread crashing can corrupt shared memory, affecting all threads in the process.
2. "Should I use multiprocessing or multithreading for my web scraper?"
   Depends on requirements:
   • If scraping many independent sites → Processes (isolation)
   • If scraping one site with many pages → Threads (share session/cookies)
   • If I/O bound (waiting for network) → Threads are more efficient
3. "How would you debug a memory leak in a multithreaded application?"
   Use tools like valgrind, check for:
   • Thread-local storage not being freed
   • Race conditions causing double allocation
   • Shared resources not being released properly

Why this matters in DevOps:

• Container design: Containers are essentially isolated processes
• Microservices: Each service runs as separate processes
• Monitoring: Need to monitor both process and thread counts
• Scaling: Understanding when to scale horizontally (processes) vs vertically (threads)
• Troubleshooting: High thread counts can indicate thread leaks, high process counts can indicate fork bombs

Signals are software interrupts delivered to a process to notify it of an event. They are a form of inter-process communication (IPC) used by the kernel or other processes.

Common Linux Signals:

Practical Signal Usage:

Real-World Scenarios:

Signal Handling in Applications:

Important Concepts:

1. Signal vs Interrupt:
   • Interrupt: Hardware to CPU
   • Signal: Software to process
2. Catchable vs Uncatchable Signals:
   • SIGKILL (9) and SIGSTOP cannot be caught or ignored
   • All other signals can be handled by the process
3. Signal Delivery:
   • Synchronous: Caused by process itself (SIGSEGV, SIGFPE)
   • Asynchronous: From outside the process (SIGINT, SIGTERM)
4. Signal Masks:
   • Processes can block signals temporarily
   • Useful in critical sections of code

Why this matters for DevOps:

• Graceful shutdowns: Critical for zero-downtime deployments
• Configuration management: SIGHUP for reloading configs without restart
• Troubleshooting: Understanding signal behavior helps debug process issues
• Container orchestration: Kubernetes uses SIGTERM then SIGKILL for pod termination
• Writing robust scripts: Proper signal handling prevents orphaned processes and resources

Linux file permissions control access to files and directories through a three-tiered system: Owner, Group, and Others.

Permission Components:

Octal vs Symbolic Notation:

Special Permissions (Setuid, Setgid, Sticky Bit):

Practical Permission Management:

Real-World Scenarios:

Permission Concepts for Directories:

• Read (r): List directory contents (ls)
• Write (w): Create/delete files in directory
• Execute (x): Access files in directory (cd into it)

Common Permission Issues and Solutions:

1. "Permission denied" when running script:
   # Script needs execute permission chmod +x script.sh # Also check shebang line #!/bin/bash
2. Can't delete file in directory:
   # Need write permission on directory, not file # Check directory permissions ls -ld /path/to/directory # Fix: chmod +w /path/to/directory
3. Apache/Nginx can't read files:
   # Web server runs as www-data user # Files need to be readable by www-data or world-readable chmod o+r file.html # World readable (not secure) chown www-data file.html # Change ownership (better) # Or use ACLs for granular control

Security Best Practices:

• Principle of Least Privilege: Give minimum necessary permissions
• Regular audits: Find world-writable files, setuid binaries
• Use groups: Instead of making files world-readable
• Secure umask: Use 027 or 077 for sensitive environments
• Limit setuid/setgid: Only essential binaries should have these

Why this matters for DevOps:

• Container security: Understanding permissions for containerized applications
• CI/CD pipelines: Setting correct permissions in deployment scripts
• Infrastructure as Code: Managing permissions through configuration
• Security compliance: Meeting security standards and audits
• Troubleshooting: Quickly resolving permission-related issues

Here's a production-ready disk monitoring script with explanations:

Key Features Explained:

1. Robust Error Handling:
   • set -euo pipefail: Exit on error, treat unset variables as errors, fail pipeline if any command fails
   • Lock file mechanism: Prevents multiple simultaneous runs
   • Dependency checking: Verifies required tools are available
2. Configuration Management:
   • Thresholds as variables for easy adjustment
   • Multiple alert channels (email, Slack, PagerDuty)
   • Logging with timestamps and colors
3. Comprehensive Monitoring:
   • Disk space usage monitoring
   • Inode usage monitoring (often overlooked)
   • Filesystem type filtering (excludes tmpfs, etc.)
4. Actionable Alerts:
   • Different severity levels (warning, critical)
   • Includes troubleshooting information
   • Multiple notification channels
5. Troubleshooting Assistance:
   • Identifies largest directories and files
   • Finds recently modified large files
   • Identifies large log files
6. Automated Cleanup:
   • Optional cleanup of old logs
   • Scheduled cleanup (first day of month)

How to Deploy and Use:

Advanced Features to Mention:

• Predictive Analysis: Could add trend analysis to predict when disk will be full
• Auto-remediation: Automatically clean up certain file types (old core dumps, temp files)
• Integration: Integrate with monitoring systems like Prometheus, Nagios
• Container Support: Monitor Docker/container disk usage
• Cloud Integration: Auto-expand volumes in AWS/GCP/Azure

Why this is a good interview answer:

1. Shows production thinking: Error handling, logging, locking
2. Demonstrates DevOps mindset: Automation, monitoring, alerting
3. Shows understanding of scale: Handles multiple disks, multiple alert channels
4. Demonstrates troubleshooting skills: Provides analysis to help fix issues
5. Shows knowledge of tools: Uses standard Unix tools effectively

I would follow a systematic approach, starting from the client side and moving toward the server side:

Step-by-Step Investigation:

Common Issues and Their Solutions:

Performance Optimization Checklist:

1. Frontend Optimization:
   • Minify and compress assets (CSS, JS)
   • Optimize images (WebP format, proper sizing)
   • Implement lazy loading
   • Use browser caching headers
2. Backend Optimization:
   • Implement caching at multiple levels
   • Optimize database queries and indexes
   • Use connection pooling
   • Implement asynchronous processing
3. Infrastructure Optimization:
   • Use CDN for static content
   • Implement load balancing
   • Enable HTTP/2 or HTTP/3
   • Use keep-alive connections
4. Monitoring & Alerting:
   • Set up real-time monitoring
   • Define performance SLOs/SLAs
   • Implement alerting for degradation
   • Regular performance testing

Tools for Different Layers:

Communication Strategy:

• Immediate Actions: Document what you checked and found
• Stakeholder Updates: Provide regular updates on investigation
• Root Cause Analysis: Document findings and lessons learned
• Prevention: Implement monitoring to detect issues earlier

Why this is a strong interview answer:

1. Shows systematic approach: Methodical troubleshooting from client to server
2. Demonstrates technical depth: Knowledge of tools at each layer
3. Shows practical experience: Real commands that can be used immediately
4. Communicates effectively: Clear explanation of what and why
5. Shows preventative thinking: Goes beyond fixing to preventing recurrence