yoklainterview sim

DevOps / Cloud Linux Process Management Signals Interview Questions

75 verified DevOps / Cloud Linux Process Management Signals interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Linux Process Management SignalsDifficulty 1
In Linux, what is the practical difference between a program and a process?
  • aThere is no difference; the two terms describe exactly the same thing
  • bA program is a static file on disk; a process is its running instance, with its own memory and PID.
  • cA program can only run once per boot, while a process can run multiple times
  • dA process is the compiled binary, while a program is what the kernel schedules on the CPU
Explanation:A program is passive on-disk data (an executable file). When it is loaded and started, the kernel creates a process: a running instance with its own address space, PID, open file descriptors, and scheduling state. The same program can back many concurrently running processes.
Linux Process Management SignalsDifficulty 1
What does PPID refer to for a running process?
  • aThe PID of the process that created it (its parent process)
  • bThe priority level assigned to the process by the scheduler
  • cThe number of threads currently running inside that process
  • dA random identifier reassigned to the process every time it wakes up from sleep
Explanation:PPID (Parent Process ID) is the PID of the process that spawned the current one, typically via fork(). Every process except PID 1 has a parent, forming the process tree visible in tools like pstree.
Linux Process Management SignalsDifficulty 1
In ps aux output, a process shown with STAT R is in which state?
  • aStopped by a job-control signal, waiting to be resumed
  • bA zombie, waiting for its parent to collect its exit status
  • cRunning or runnable, executing on a CPU or waiting in the run queue.
  • dPermanently blocked on disk I/O with no way to be interrupted
Explanation:R means the process is in the TASK_RUNNING state from the kernel's point of view: it is either actually executing on a CPU right now or sitting in the run queue ready to be scheduled.
Linux Process Management SignalsDifficulty 1
A process shown with STAT S in ps aux is described as being in "interruptible sleep". What does that mean?
  • aThe process has crashed and cannot be woken up under any circumstance
  • bThe process is consuming 100% CPU while waiting
  • cThe process can only be woken up by SIGKILL, no other signal works
  • dWaiting for an event; a pending signal can interrupt the wait early.
Explanation:Interruptible sleep (S) is the most common idle state: the process is blocked waiting for some condition (data on a socket, a timer, a mutex), but a pending signal can interrupt that wait and hand control back to the process before the condition is met.
Linux Process Management SignalsDifficulty 2
What is the key practical difference between STAT D (uninterruptible sleep) and STAT S (interruptible sleep)?
  • aThere is no real difference; D and S are just two names for the exact same kernel state
  • bA D-state process usually can't respond to signals, including kill, until its I/O completes.
  • cA process in D state has already been reaped by its parent, while S processes are still alive
  • dD processes always consume more CPU than S processes while waiting
Explanation:D (uninterruptible sleep) typically happens during direct hardware/I/O waits (disk, some NFS operations). The kernel does not let a signal interrupt that wait, so even kill -9 appears to have no effect until the I/O finishes or times out — the process simply cannot check for pending signals while stuck in that kernel path.
Linux Process Management SignalsDifficulty 2
What is a zombie process (STAT Z)?
  • aIt has exited and released its resources, but keeps a process-table entry until reaped.
  • bA process that is still actively running but consuming zero CPU
  • cA malicious process injected by malware that hides from ps
  • dA process that was killed with SIGKILL but whose memory was never freed by the kernel
Explanation:A zombie has already exited: its memory, file descriptors, and other resources are released. All that remains is a small process-table entry holding its PID and exit status, kept around so the parent can retrieve that status via wait()/waitpid(). It is not consuming CPU or memory beyond that entry.

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview