Skip to content

Linux Admin Interview — Intermediate

Use for: process management, signals, boot process, systemd, package managers, environment variables, scheduling, zombie/orphan processes.

Search keywords: ps top htop kill signal SIGTERM SIGKILL SIGHUP boot process GRUB initramfs systemd systemctl journalctl apt yum dnf redirection environment variable PATH bashrc cron crontab zombie process orphan process

Q9. How do you see what is running and stop a process?

ps aux for a snapshot, top or htop for a live view, and kill to send a signal to a PID.

$ ps aux --sort=-%mem | head -3
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      2696  0.0  0.0   7888  4044 ?        R    06:43   0:00 ps aux --sort=-%mem
root         1  0.2  0.0   4324  3592 ?        Ss   06:42   0:00 bash

The detail that signals experience: kill does not mean "force stop", it means "send a signal". kill <pid> sends the polite SIGTERM and lets the process clean up; kill -9 <pid> sends SIGKILL, which the process cannot catch or ignore. Reach for -9 only after TERM has failed, because SIGKILL gives the process no chance to flush buffers or release locks.

Q10. What is a signal? Name the ones you use most.

A signal is an asynchronous notification the kernel delivers to a process. The three every candidate should know by number:

$ echo "HUP=$(kill -l HUP) KILL=$(kill -l KILL) TERM=$(kill -l TERM)"
HUP=1 KILL=9 TERM=15

SIGTERM (15) asks a process to shut down gracefully and can be handled. SIGKILL (9) cannot be caught, blocked, or ignored, so the process dies immediately with no cleanup. SIGHUP (1) originally meant the terminal hung up, but many daemons now treat it as "reload your config without restarting". Knowing that SIGKILL is uncatchable explains why a wedged process sometimes ignores everything except -9.

Q11. Walk me through the Linux boot process.

At a high level: firmware (BIOS or UEFI) runs its power-on checks and hands off to a bootloader, usually GRUB. GRUB loads the kernel and an initial ramdisk (initramfs) into memory. The kernel initializes hardware, mounts the root filesystem, and starts the first process, PID 1, which on every current mainstream distribution is systemd. systemd then brings the system up to its target state by starting services in dependency order.

The modern detail worth adding: systemd replaced the old SysV init and numbered runlevels with targets (for example multi-user.target for a server, graphical.target for a desktop).

What they're really testing: whether you can reason about a box that will not come up, by knowing the stages where it can get stuck.

Q12. How do you manage services with systemd?

systemctl is the control surface, and journalctl reads the logs.

$ systemctl start hello.service
$ systemctl status hello.service
* hello.service - Hello demo service
     Loaded: loaded (/etc/systemd/system/hello.service; static)
     Active: active (running) since Wed 2026-06-17 06:43:44 UTC; 11ms ago
   Main PID: 73 (sleep)

The distinction interviewers fish for: systemctl start runs a service now, systemctl enable makes it start on boot, and they are independent. A service can be enabled but stopped, or running but not enabled (so it vanishes after a reboot). For logs, journalctl -u <service> scopes to one unit, and -f follows it live.

Q13. How do package managers work, and how do apt and yum/dnf differ?

They resolve and install software along with its dependencies from configured repositories. On Debian and Ubuntu the high-level tool is apt (sitting on top of the lower-level dpkg); on RHEL, Fedora, and their relatives it is dnf (the successor to yum, on top of rpm). The split that matters: dpkg/rpm install a single package file you already have, while apt/dnf talk to repositories and pull in dependencies automatically. If someone hands you a lone .deb, dpkg -i installs it but will not fetch its dependencies; apt install ./file.deb will.

Q14. What is the difference between >, >>, and 2>&1?

> redirects stdout and truncates the target file first, so it overwrites. >> appends instead of truncating. 2>&1 redirects stderr to the same place stdout is going. The combination people get wrong is ordering: command > file 2>&1 works (point stdout at the file, then send stderr to that same place), but command 2>&1 > file sends stderr to the original terminal because you redirected it before moving stdout. State the rule plainly: redirections are evaluated left to right.

Q15. How do environment variables work, and where do you set them?

An environment variable is a key-value pair inherited by child processes. You set one for the current shell with NAME=value and export it to children with export NAME=value.

$ echo "$PATH" | tr ":" "\n" | head -4
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin

The interview hook is where you persist them: ~/.bashrc runs for interactive non-login shells (a new terminal tab), while a login shell (an SSH session) reads ~/.bash_profile (or ~/.profile) and does not read ~/.bashrc on its own unless that file sources it, which Ubuntu's default ~/.profile does. Put a variable in the wrong one and it can mysteriously be missing in one context but present in the other. PATH is just a colon-separated list the shell searches, in order, to find a command.

Q16. How do you schedule a recurring task?

The classic answer is cron: you add a line to a crontab with five time fields (minute, hour, day-of-month, month, day-of-week) and a command. 0 2 * * * runs at 2 a.m. daily. The modern alternative is systemd timers, which are more verbose but give you logging through the journal, dependency handling, and the ability to catch up on a missed run (Persistent=true). For a quick periodic job, cron is fine; for anything that needs observability, timers are the better answer, and saying so shows range.

Q17. What is a zombie process, and what is an orphan?

A zombie is a process that has finished but whose parent has not yet read its exit status, so it lingers in the process table as a Z state with no resources except that one entry. An orphan is a process whose parent died first; it gets re-parented to PID 1 (systemd), which adopts it and reaps it when it exits. The practical point: a single zombie is harmless, but a flood of them means a parent that is not calling wait(), which is a bug in that parent, not something you fix by killing the zombie (it is already dead).