15 Linux Interview Questions and Answers for System Administrators

Most Linux interview lists recycle the same 10 questions from a decade ago, and many of the “official” answers are outdated or no longer apply to modern Linux distributions.

While the fundamentals haven’t changed, Linux itself has evolved. Tools like journalctl have replaced older logging methods on many distributions, ss has largely replaced netstat, and several traditional services and commands are no longer the default.

If you’re preparing for a Linux System Administrator, DevOps, or Site Reliability Engineer (SRE) interview, simply memorizing answers isn’t enough.

Interviewers often ask follow-up questions to see whether you truly understand the concepts and can solve real-world problems. Being able to explain why something works and demonstrate it with the correct Linux command can make all the difference.

We originally published this interview guide several years ago, but it was due for an update. Some of the services mentioned in the original version are no longer used on modern Linux distributions, and one of the answers was technically incorrect.

We’ve completely revised the guide to reflect today’s Linux environments, replacing outdated information with practical, accurate explanations and the commands you’ll actually use as a Linux administrator.

Whether you’re preparing for your first Linux interview or brushing up on your skills before your next role, these 15 interview questions will help you build the confidence to answer beyond textbook definitions and demonstrate real hands-on Linux knowledge.

1. How do you Suspend a Running Process and Move it to the Background?

Press Ctrl+Z while a process is running in the foreground. This sends the SIGTSTP (Terminal Stop) signal, which pauses the process without terminating it and returns you to the shell prompt.

Once the process is suspended, you can manage it using the following job control commands:

• bg – Resumes the suspended job in the background, allowing it to continue running while you use the same terminal.
• fg – Brings a background or suspended job back to the foreground.
• jobs – Lists all jobs running or suspended in the current shell session, along with their job numbers (such as %1, %2, and so on).

For example, suppose you start a large rsync backup and then realize you need the terminal for another task. Instead of stopping the transfer and starting over, press Ctrl+Z to suspend it, run bg to continue it in the background, and keep working in the same terminal.

If you later need to interact with the process again, use fg %1 (replace %1 with the appropriate job number) to bring it back to the foreground.

$ rsync -av /home/user/Documents/ /backup/ 
^Z [1]+ Stopped rsync -av /home/user/Documents/ /backup/ 
$ bg [1]+ rsync -av /home/user/Documents/ /backup/ & 
$ jobs [1]+ Running rsync -av /home/user/Documents/ /backup/ & 
$ fg %1 rsync -av /home/user/Documents/ /backup/

2. What’s the Minimum Partition Setup to Install Linux, and How do You Check boot Messages?

The minimum partition required to install Linux is a single root (/) partition. The system can boot and run with just this partition.

However, most production systems use a few additional partitions or volumes:

• / (root) – Stores the operating system and applications.
• /boot – Contains the kernel and bootloader files. This is often kept separate, especially on systems that use full-disk encryption.
• Swap – Provides virtual memory when RAM is low and is also used for hibernation. Modern systems typically don’t need the old “swap = 2× RAM” rule. A small swap partition or swap file is enough for most workloads.

To troubleshoot boot problems or review what happened during startup, you can use these commands:

• dmesg – Displays kernel boot messages and the kernel ring buffer. It’s useful for checking hardware detection, driver loading, and kernel-related errors.
• journalctl -b – Shows the complete log for the current boot on systemd-based distributions such as Ubuntu, RHEL, Fedora, Debian, and Rocky Linux.
• journalctl -b -p err – Displays only error messages from the current boot, making it easier to spot problems.

For example:

$ dmesg | less

$ journalctl -b

$ journalctl -b -p err

On older Linux distributions that used the SysV init system, boot logs were commonly stored in files such as /var/log/boot.log. On modern Linux distributions that use systemd, however, journalctl is the primary tool for viewing boot logs and troubleshooting startup issues.

3. Which Daemon Tracks System Events on a Modern Linux System?

Years ago, the expected answer to this question was syslogd, because it was the standard system logging daemon on traditional Unix and Linux systems. While you may still hear it mentioned in interviews, most modern Linux distributions have moved to newer logging solutions.

Today, the logging system depends on the Linux distribution you’re using:

• Ubuntu and Debian – Use rsyslog by default, which stores logs as plain text files under directories such as /var/log/.
• RHEL, Rocky Linux, Fedora, and other systemd-based distributions – Use systemd-journald, which stores logs in a binary journal that you view using the journalctl command.

Knowing which logging system your distribution uses is important because the commands for viewing logs are different.

For example, to check SSH login activity:

# RHEL, Rocky Linux, Fedora
$ journalctl -u sshd

# Ubuntu and Debian
$ grep 'sshd' /var/log/auth.log

If you’re troubleshooting a service, you can also view its logs with:

$ journalctl -u nginx
$ journalctl -u sshd

Understanding the difference between rsyslog and systemd-journald shows that you’re familiar with how logging works on modern Linux systems, not just older distributions.

4. What do you need Before Running fsck on the root Partition?

Before running fsck on the root filesystem, it must not be mounted in read-write mode. Running fsck on an active, writable filesystem can lead to data corruption because the operating system may still be writing to the disk while the check is in progress.

The safest approaches are:

• Boot into rescue mode, single-user mode, or from a live Linux environment, and run fsck when the root filesystem is not in use.
• If the root filesystem is mounted, remount it as read-only before running fsck (when appropriate).
• If you can’t run fsck immediately, schedule a filesystem check for the next boot.

For example:

# Remount the root filesystem as read-only
$ mount -o remount,ro /

# Run a filesystem check (replace the device as needed)
$ fsck /dev/sda2

To force a filesystem check during the next boot:

# Older Linux systems
$ touch /forcefsck

On modern systemd-based distributions, you can also add the kernel boot parameter:

fsck.mode=force

This tells the system to perform a filesystem check during startup.

5. How do You Copy a Directory tree While Preserving its Structure?

A traditional Unix tool for copying an entire directory tree is cpio. It preserves the directory hierarchy and can also retain file permissions and timestamps.

Although it isn’t used as frequently today, it still appears in certification exams such as The LFCS Certification Preparation Course and in some Linux interviews.

A classic example is:

$ find /home -depth | cpio -pdm /backup

Here’s what each part does:

• find /home -depth – Lists all files and directories under /home, processing files before their parent directories.
• cpio -p – Uses pass-through mode to copy files directly to another directory.
• -d – Creates destination directories if they don’t already exist.
• -m – Preserves the original modification times.

Although cpio is still worth knowing for certifications and interviews, most Linux administrators now use rsync for this task because it’s simpler, faster, and can resume interrupted transfers.

For example:

$ rsync -a /home/ /backup/

The -a (archive) option preserves the directory structure, permissions, ownership, timestamps, symbolic links, and other important file attributes, making it the preferred choice for most real-world Linux systems.

6. How do You Automate Log Rotation?

The standard tool for automating log rotation on Linux is logrotate. It manages log files by rotating, compressing, removing, and recreating them based on rules you define. This prevents log files from growing indefinitely and consuming valuable disk space.

On most Linux distributions, including Ubuntu, Debian, RHEL, Rocky Linux, and Fedora, logrotate is installed by default and runs automatically through cron or a systemd timer.

Configuration files are stored in:

• /etc/logrotate.conf – The main configuration file.
• /etc/logrotate.d/ – Contains separate configuration files for individual services such as Apache, Nginx, MySQL, and others.

A typical logrotate configuration lets you control:

• How often logs are rotated (daily, weekly, monthly)
• How many old log files are retained
• Whether rotated logs are compressed
• Whether empty log files should be ignored
• Whether a service should be restarted after rotation

For example:

/var/log/myapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

This configuration rotates the log every week, keeps four archived copies, compresses old logs, ignores missing log files, and skips rotation if the log file is empty.

One important point worth mentioning in an interview is that systemd journal logs are not managed by logrotate. Instead, systemd-journald manages its own logs.

To reduce journal logs to a maximum size:

# Reduce journal size to 500 MB
$ journalctl --vacuum-size=500M

# To remove journal entries older than two weeks:
$ journalctl --vacuum-time=2weeks

Permanent journal storage limits are configured in:

/etc/systemd/journald.conf

For example, you can set options such as SystemMaxUse to limit how much disk space the journal is allowed to use.

7. How do You Find Out Who Scheduled a Job With at?

The at command schedules a one-time task to run at a specified date and time. To view pending jobs, use at -l or its equivalent atq.

at -l
or
atq

The output displays the job number, scheduled execution time, and the user who created the job.

Example:

3   Sat Aug  1 02:00:00 2026 a username

# To view the commands that a scheduled job will execute, use:
at -c 3

(Replace 3 with the appropriate job number.) If you no longer need a scheduled job, you can remove it with:

atrm 3
or
at -r 3

This command deletes the specified job from the queue. Interviewers often ask this question to test whether you understand the difference between at and cron.

• at is used for one-time scheduled tasks.
• cron is used for recurring tasks that run at regular intervals, such as every hour, every day, or every week.

For example, if you’re asked to schedule a one-time database backup at 2:00 AM tonight without modifying the system crontab, at is the correct tool.

8. How do You View the Contents of a Tar Archive Without Extracting it?

To list the contents of a tar archive without extracting any files, use the tar command with the -t (list) option.

tar -tvf backup.tar.gz

Here’s what each option does:

• -t – Lists the contents of the archive instead of extracting it.
• -v – Displays detailed (verbose) information, including file permissions, owner, group, size, and modification time.
• -f – Specifies the archive file to operate on.

A typical output looks like this:

-rw-r--r-- root/root      1024 2026-07-30 10:15 backup/file1.txt
drwxr-xr-x root/root         0 2026-07-30 10:15 backup/config/
-rw-r--r-- root/root      2048 2026-07-30 10:16 backup/config/app.conf

Listing an archive before extracting it is a good practice because it lets you verify the files it contains and their directory structure.

One useful detail is that modern GNU tar automatically detects common compression formats such as gzip (.tar.gz), bzip2 (.tar.bz2), and XZ (.tar.xz). This means you usually don’t need to specify options like -z, -j, or -J explicitly.

For example, these commands all work with modern GNU tar:

tar -tf backup.tar.gz
tar -tf backup.tar.bz2
tar -tf backup.tar.xz

Older versions of tar often required compression-specific options, which is why you’ll still see commands like tar -ztvf archive.tar.gz in older documentation.

9. What is a Page Fault, and When Does it Happen?

A page fault occurs when a running process tries to access a memory page that is not currently mapped into physical RAM. Contrary to a common misconception, page faults do not occur when a program exits, they happen while a program is actively running and requesting memory.

When a page fault occurs, the Linux kernel determines whether the required page can be mapped immediately or whether it must first be loaded from disk.

There are two types of page faults you should know:

• Minor page fault – The required page is already available in memory (for example, in the page cache or shared with another process). The kernel simply updates the page tables, so no disk I/O is required.
• Major page fault – The required page must be loaded from disk (such as from an executable file, a memory-mapped file, or swap). Because disk access is much slower than RAM, frequent major page faults can significantly reduce system performance.

You can monitor system-wide memory and swap activity with:

$ vmstat 1

Pay attention to the si (swap in) and so (swap out) columns. Consistent activity in these columns may indicate that the system is under memory pressure.

To view page fault statistics for a specific process, use:

$ ps -o min_flt,maj_flt -p 

Here:

• min_flt shows the number of minor page faults.
• maj_flt shows the number of major page faults.

A high number of major page faults often indicates that the system is running low on available memory and spending time reading pages from disk instead of RAM.

10. What are Return Codes, and How do you use Them?

A return code, also known as an exit status, is the value a program returns to the shell when it finishes executing. By convention:

• 0 indicates the command completed successfully.
• Any non-zero value indicates an error or abnormal condition. The exact meaning of the non-zero value depends on the program that generated it.

To check the exit status of the last command, use:

$ grep "error" logfile.txt
$ echo $?

If grep finds a match, echo $? returns 0. If no match is found, it returns a non-zero exit status.

Exit codes are especially useful in shell scripts, where you can control what happens next based on whether a command succeeds or fails.

For example:

# Run cmd2 only if cmd1 succeeds
$ cmd1 && cmd2

# Run cmd2 only if cmd1 fails
$ cmd1 || cmd2

This makes it easy to automate tasks and handle errors without writing complex logic.

11. What’s the Difference Between a Hard Link and a Symbolic Link?

Both hard links and symbolic (soft) links provide another way to access a file, but they work differently.

A hard link is another directory entry that points to the same inode as the original file. Since both names refer to the same data on disk, deleting the original filename does not remove the file as long as at least one hard link still exists.

A symbolic link (or symlink) is a special file that stores the path to another file or directory. If the original file is deleted or moved, the symlink becomes broken because its target no longer exists.

Create them using:

# Create a hard link
$ ln target_file hardlink

# Create a symbolic link
$ ln -s target_file symlink

There are a few important differences:

In practice, symbolic links are used far more often because they’re flexible and can point to files or directories anywhere on the system. Hard links are mainly used when multiple filenames need to reference the same underlying file without duplicating its data.

12. What’s the Difference Between kill -9 and kill -15?

The kill command sends signals to processes. The two signals most commonly discussed in interviews are SIGTERM (15) and SIGKILL (9).

• kill -15 sends SIGTERM, which politely asks a process to terminate. The process has a chance to close files, save data, release resources, and exit cleanly.
• kill -9 sends SIGKILL, which immediately stops the process. The process cannot catch or ignore this signal, so it has no opportunity to perform any cleanup.

In most cases, you should try SIGTERM first. In fact, if you don’t specify a signal, kill sends SIGTERM by default.

For example:

# Send SIGTERM (default)
$ kill 1234

# Equivalent to the above
$ kill -15 1234

# Forcefully terminate the process
$ kill -9 1234

Use SIGKILL only when a process is completely unresponsive and does not exit after receiving SIGTERM. Forcefully killing applications such as databases can interrupt ongoing operations and may leave data in an inconsistent state.

13. How do You Check Open Ports and Listening Services?

The recommended tool for viewing network connections on modern Linux systems is ss. It has replaced netstat on most distributions because it’s faster and reads socket information directly from the kernel.

To display all listening TCP and UDP ports along with the owning process, run:

$ ss -tulpn

The options mean:

• -t – Show TCP sockets.
• -u – Show UDP sockets.
• -l – Display only listening sockets.
• -p – Show the process name and PID using each socket.
• -n – Display numeric addresses and port numbers instead of resolving hostnames.

Example output:

Netid State  Recv-Q Send-Q Local Address:Port  Process
tcp   LISTEN 0      128    0.0.0.0:22         users:(("sshd",pid=892,fd=3))
tcp   LISTEN 0      511    0.0.0.0:80         users:(("nginx",pid=1215,fd=6))

If a service fails to start, one of the first things to check is whether another process is already using the required port.

For example:

# Check the service status
$ systemctl status nginx

# See if port 80 is already in use
$ ss -tulpn | grep :80

This quickly tells you whether the service is listening on the expected port or if another application has already claimed it.

14. What is the OOM Killer, and How Does it Decide What to Kill?

The Out-Of-Memory (OOM) killer is a Linux kernel feature that automatically terminates a process when the system runs out of available memory and cannot recover by using swap space. Its goal is to free memory and keep the system running instead of allowing it to become completely unresponsive.

The OOM killer does not choose a process at random. The kernel assigns each process an OOM score based on factors such as its memory usage and other criteria. Processes with a higher score are more likely to be terminated.

To view the OOM score of a process, run:

$ cat /proc//oom_score

You can also influence how likely a process is to be selected by adjusting its oom_score_adj value:

$ cat /proc//oom_score_adj

The value ranges from -1000 to 1000:

• -1000 – Prevents the process from being selected by the OOM killer.
• 0 – Uses the default behavior.
• 1000 – Makes the process much more likely to be terminated.

For example, to protect a critical process:

$ echo -1000 | sudo tee /proc//oom_score_adj

If a system is repeatedly invoking the OOM killer, it’s usually a sign that it needs more available memory, a larger swap space, or applications that use less memory.

15. How do You Find Files Modified in the Last 24 Hours?

To find files that were modified within the last 24 hours, use the find command with the -mtime option:

$ find /var/log -mtime -1

Here’s what it means:

• find /var/log – Searches for files under the /var/log directory.
• -mtime -1 – Finds files modified less than one day ago.

You can also search for other time ranges:

# Modified exactly one day ago
$ find /var/log -mtime 1

# Modified more than one day ago
$ find /var/log -mtime +1

If you need more precise control, use -mmin, which works in minutes instead of days.

For example, to find files modified within the last hour:

$ find /var/log -mmin -60

This command is especially useful when troubleshooting issues. If a service suddenly stops working, you can quickly identify log files, configuration files, or other files that were recently modified and investigate what changed before the problem occurred.

Conclusion

Linux interview questions are designed to test more than your ability to memorize commands. Interviewers want to know whether you understand how Linux works, can explain key concepts clearly, and know which commands to use when troubleshooting real systems.

The 15 questions in this guide cover topics you’ll encounter in many Linux system administrator, DevOps, and cloud engineering interviews.

Spend some time practicing each command on a Linux machine, experiment with different options, and try to understand the output instead of simply memorizing it. That hands-on experience will make it much easier to answer follow-up questions with confidence.

If you’re preparing for Linux interviews, keep this guide as a quick reference and revisit these concepts regularly. A solid understanding of the basics is often what sets successful candidates apart.