This page needs a newer browser to run its tools. You can still read everything here.

Processes: creation, life cycle, signals and IPC interview questions

Interview questions on “Processes: creation, life cycle, signals and IPC”: warm-ups, then what each harder question tests and how a good answer starts.

21 questions: 7 warm-ups and 14 with model answers · Levels: Fresher to staff

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

What is the difference between a program, a process and a thread?

Answered in the lesson The process: address space, PCB and states
Fresher to mid

What does the kernel save and restore in a context switch?

Answered in the lesson Context switches and their real cost
Fresher

What does fork return, and how do the parent and the child tell which one they are?

Answered in the lesson Creating processes: fork, exec and wait
Fresher

What is a zombie process, and how is it different from an orphan?

Answered in the lesson Exit, zombies, orphans and daemons
Fresher

What is the difference between SIGTERM and SIGKILL, and why does a service manager send SIGTERM first?

Answered in the lesson Signals and safe signal handlers
Fresher to mid

When would you use a pipe, a FIFO or a Unix domain socket to connect two processes?

Answered in the lesson IPC: pipes, FIFOs and Unix domain sockets
Fresher to mid

When is shared memory a better choice than message passing between processes, and what does it cost you?

Answered in the lesson IPC: shared memory and message queues

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Mid to senior

A monitoring alert flags a service as leaking: its virtual size is 40 GB, while its resident memory has stayed near 300 MB for days. Is it a leak? Explain what can make the virtual size so large, and how you would find out.
What it tests

The difference between mapped address space and memory in use, the regions that reserve address space, and reading a process's memory map before drawing conclusions.

First step

Separate the two numbers. The virtual size counts every mapped region, used or not; resident memory counts the pages actually in RAM, and a leak shows as resident memory that keeps growing. So a flat 300 MB says no leak so far. Then list where 40 GB of reservations come from by reading /proc/<pid>/maps or pmap: stacks, allocator arenas, runtime heap reservations and mapped files.
Follow-ups
- How would you tell a real leak from reserved address space, over time?
- Why does a program built with AddressSanitizer show terabytes of virtual memory?
- Could a large virtual size still cause trouble, even if nothing is resident?
From the lesson The process: address space, PCB and states
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Senior to staff

You are writing the process table of a small kernel for a microcontroller without an MMU. Which fields does each entry need, which of them change at every context switch, and what can you leave out compared with Linux's task_struct?
What it tests

Knowing what a process control block is for, field by field, and fitting it to hardware without virtual memory, a file system or many users.

First step

Start from what the kernel must do with an entry: stop the task at any instruction and resume it, choose which task runs next, and know why a task waits. That gives the saved registers or the saved stack pointer, the state, the priority and queue links, and the wait reason. Then go through task_struct's groups and drop those the hardware or the system cannot use.
Follow-ups
- Where exactly do the saved registers live on a Cortex-M class core?
- How do you catch a task that overflows its stack without an MMU?
- Do you need a parent field and an exit status at all?
From the lesson The process: address space, PCB and states
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

To raise throughput, a service on a 4-core machine went from 8 to 64 worker threads. Throughput fell by a fifth, and context switches rose from about 5,000 to 250,000 a second. Explain what happened and what you would change.
What it tests

Turning a switch rate into a share of CPU time, telling preemption from blocking, and sizing a thread pool to the hardware and the work.

First step

Turn the rate into time: 250,000 switches a second on 4 cores is about 62,500 per core, one every 16 microseconds. Then ask which kind they are, voluntary or involuntary, because too many runnable threads and threads blocking on a shared lock call for different fixes.
Follow-ups
- How do you tell whether the new switches are voluntary or involuntary, and why does it matter?
- When is it right to have more threads than cores?
- What would you change if the work were mostly waiting for I/O?
From the lesson Context switches and their real cost
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to staff

Your pipe ping-pong benchmark reports about 3 microseconds per hand-off on one Linux server and about 40 on a laptop. How do you make the measurement trustworthy, and what could explain the gap?
What it tests

Measuring a short event honestly, and knowing what a hand-off contains beyond the switch: wake-ups, other cores, power states, mitigations and virtualisation.

First step

First make the two numbers comparable: many runs with the median and the spread, the same no-switch baseline, the same pinning, and the CPU model, kernel and mitigations written down. Then ask what each hand-off contains: on one core it is a switch, across cores it is also a wake-up of a core that may be idle.
Follow-ups
- Which setup answers what a switch costs, and which answers what a hand-off costs in your service?
- How would you check that each round trip really makes two switches?
- What changes when the benchmark runs inside a virtual machine?
From the lesson Context switches and their real cost
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to staff

A server forks a helper process for each request, which then runs an external tool. As the server's own heap grew to 20 GB, each fork started to take tens of milliseconds, and requests queue behind it. Explain why, and what you would change.
What it tests

What fork copies even with copy-on-write, why its cost grows with the parent, and the alternatives for starting programs from a large process.

First step

Copy-on-write saves copying the pages, not the bookkeeping: fork still duplicates the page tables of all 20 GB and marks every writable page read-only, and the parent's next writes then fault and copy pages. So the cost grows with the parent's memory even though the child execs a small tool at once.
Follow-ups
- Why do the parent's own requests get slower for a while after each fork?
- What does posix_spawn change, and what does vfork do?
- How would you design this if the helpers must share some of the server's state?
From the lesson Creating processes: fork, exec and wait
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

After a change that added a fork to a service, some log lines appear twice in the collected logs, yet never when a developer runs the service in a terminal. Explain what happens, and fix it.
What it tests

stdio buffering that depends on the output device, fork copying a process's memory, and the difference between exit and _exit.

First step

Ask where the output goes. In a terminal, standard output is line buffered, so every line is written before the fork; into a pipe or a file, as a log collector reads it, it is fully buffered, so recent lines are still in the buffer when fork copies the memory, and both processes later flush them.
Follow-ups
- Why does it happen only for some lines?
- Would writing logs to standard error avoid it?
- How should the child end, and why does it matter?
From the lesson Creating processes: fork, exec and wait
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A job runner forks a worker for each task and collects workers in a SIGCHLD handler that calls waitpid once. Under light load all is well, but under heavy load zombies pile up, although every worker exits. Explain why, and fix it.
What it tests

Signal coalescing, writing a correct SIGCHLD handler, and the other ways to collect children without losing their statuses.

First step

Notice what differs under load: several workers exit before the handler runs. Standard signals do not queue, so those exits arrive as one SIGCHLD, and a handler that collects one child per signal leaves the others as zombies. The fix is a loop on waitpid(-1, &status, WNOHANG) until it returns 0 or -1.
Follow-ups
- What else must a SIGCHLD handler take care of?
- How can you avoid doing the work in a signal handler at all?
- When would you set SIGCHLD to SIG_IGN instead?
From the lesson Exit, zombies, orphans and daemons
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to senior

You start a long job over SSH with ./job & and log out. When you log back in, the job is gone, with no error in its log. Explain what ended it, and how you would keep such a job running properly.
What it tests

Sessions, controlling terminals and SIGHUP, and the right ways to detach a program: setsid, nohup, terminal multiplexers and service managers.

First step

Follow the session: the job is a member of the login session whose controlling terminal is the SSH connection. When the session ends, the job receives SIGHUP, from the kernel or from the shell, and SIGHUP's default action ends the process, silently, before it can write anything.
Follow-ups
- What do nohup and setsid each change?
- Why is a service manager the better answer for a job that must keep running?
- What happens to a stopped job when its session ends?
From the lesson Exit, zombies, orphans and daemons
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

During every deployment, a few requests to your HTTP service fail with reset connections. The orchestrator sends SIGTERM, waits 30 seconds, then sends SIGKILL, and the service installs no signal handlers. Explain what happens to the requests in flight, and design the service's shutdown.
What it tests

The default actions of SIGTERM and SIGKILL, turning a signal into a flag the main loop acts on, draining work within a deadline, and the order of steps with the routing layer.

First step

Start from the default action: SIGTERM ends the process at once, so every request it holds is cut off and the 30 seconds are never used. Then let the service decide when to stop: a handler that only sets a flag, after which the main loop stops accepting, finishes the requests in flight and exits before the grace period ends.
Follow-ups
- What if some requests take longer than the grace period?
- Why can new requests still arrive after SIGTERM, and what do you do about them?
- How would you test that the shutdown really drains?
From the lesson Signals and safe signal handlers
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to staff

A daemon reloads its configuration on SIGHUP. Its handler logs with printf, then parses the new file and builds tables with malloc. Once every few weeks, right after a reload, the daemon stops responding and uses no CPU at all. Explain the hang, and redesign the reload.
What it tests

Async-signal-safety, what a handler can interrupt, deadlocks on library locks, and moving work out of handlers into the main loop or a signal descriptor.

First step

Ask what the handler can interrupt: any instruction of the main code, sometimes inside printf or malloc while they hold a lock. The handler's own printf or malloc then waits for a lock that the interrupted code cannot release until the handler returns, a deadlock at 0 % CPU. The fix is a handler that only sets a flag.
Follow-ups
- How would you confirm the deadlock on the hung process?
- Why does it happen only once every few weeks?
- What if the main loop is blocked in a long call when SIGHUP arrives?
From the lesson Signals and safe signal handlers
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Your program starts a filter such as tr as a child, with one pipe to its standard input and one from its standard output. It writes all its input first, then reads the output. With 1 KB of input it works; with 1 MB it hangs at 0 % CPU. Explain why, and fix it.
What it tests

Pipe capacity and blocking writes, a deadlock between two processes that each wait for the other, and reading and writing a child's pipes at the same time.

First step

Ask who waits for whom. The filter writes output while it reads input, but the parent reads nothing until it has written everything. With 1 MB the output pipe fills at its capacity, 65,536 bytes here, so the child blocks in write and stops reading; then the input pipe fills and the parent blocks too.
Follow-ups
- Why does the same program work with 1 KB?
- How would you fix it without threads?
- What else must the parent do so that the child's output ends?
From the lesson IPC: pipes, FIFOs and Unix domain sockets
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Senior to staff

A helper running as root serves an unprivileged web worker over a Unix domain socket. The worker sends a file path, the helper checks that it lies inside /srv/uploads and replies allowed, and the worker then opens the file itself. Explain what is weak about this design, and redesign it.
What it tests

Least privilege, the gap between checking a path and using it, peer credentials on a local socket, and passing open descriptors with SCM_RIGHTS.

First step

Find what the check protects, and when. The helper checks a path, but the worker opens it later under its own rights, and the path's meaning can change in between, through a symbolic link for example. Move the open to where the check happens: verify the peer, open the file in the helper and send the open descriptor.
Follow-ups
- How does the helper know that a request comes from the web worker?
- Which ways of opening make the helper's own open safe against links?
- How would you test the redesign?
From the lesson IPC: pipes, FIFOs and Unix domain sockets
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Eight worker processes count requests in a shared memory page with counter++ on a volatile long. Under load the counter reports 20 % fewer requests than the access log. Explain why, fix it, and say how you would prove the fix.
What it tests

Lost updates in shared memory, atomics against process-shared locks, per-worker counters and cache lines, and a test that fails on the broken version.

First step

counter++ is a load, an add and a store, and volatile does not make it one step: two workers that load the same value both store it plus one, and a request disappears. Under load more increments overlap, so more disappear. Make the update atomic, or give each worker a counter of its own and sum them when reading.
Follow-ups
- Atomic add, a process-shared mutex or per-worker counters, which would you pick and why?
- What happens if a worker dies while it holds the lock?
- How do you test that no update is lost any more?
From the lesson IPC: shared memory and message queues
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Senior to staff

A capture process produces 1920 by 1080 frames of 4 bytes per pixel at 60 frames a second, and an encoder process on the same machine consumes them. Estimate the data rate, choose the IPC, and explain how the processes coordinate so that the encoder never reads a half-written frame.
What it tests

Estimating bandwidth, the cost of copying through the kernel, a ring of shared slots whose ownership is handed over, and back-pressure when the consumer falls behind.

First step

Start with the numbers: 1920 x 1080 x 4 is 8,294,400 bytes, about 8.3 MB a frame, so 60 a second is about 498 MB a second. A pipe or socket would copy that twice, about 1 GB a second of copying. So use shared memory, a ring of frame slots, and a small handshake that passes ownership of each slot.
Follow-ups
- How does the encoder learn that a new frame is ready without polling?
- What happens when the encoder is slower than the camera?
- How would you keep the design safe if either process crashes?
From the lesson IPC: shared memory and message queues
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

The lessons of this module

The process: address space, PCB and states Free: 20 minutes
Context switches and their real cost Free lesson, Pro answers: 15 minutes
Creating processes: fork, exec and wait Free lesson, Pro answers: 15 minutes
Exit, zombies, orphans and daemons Free lesson, Pro answers: 15 minutes
Signals and safe signal handlers Free lesson, Pro answers: 25 minutes
IPC: pipes, FIFOs and Unix domain sockets Free lesson, Pro answers: 20 minutes
IPC: shared memory and message queues Free lesson, Pro answers: 20 minutes

All Operating Systems interview questions · The Operating Systems track

Warm-up questions

What is the difference between a program, a process and a thread?

What does the kernel save and restore in a context switch?

What does fork return, and how do the parent and the child tell which one they are?

What is a zombie process, and how is it different from an orphan?

What is the difference between SIGTERM and SIGKILL, and why does a service manager send SIGTERM first?

When would you use a pipe, a FIFO or a Unix domain socket to connect two processes?

When is shared memory a better choice than message passing between processes, and what does it cost you?

Questions with model answers

A monitoring alert flags a service as leaking: its virtual size is 40 GB, while its resident memory has stayed near 300 MB for days. Is it a leak? Explain what can make the virtual size so large, and how you would find out.

You are writing the process table of a small kernel for a microcontroller without an MMU. Which fields does each entry need, which of them change at every context switch, and what can you leave out compared with Linux's task_struct?

To raise throughput, a service on a 4-core machine went from 8 to 64 worker threads. Throughput fell by a fifth, and context switches rose from about 5,000 to 250,000 a second. Explain what happened and what you would change.

Your pipe ping-pong benchmark reports about 3 microseconds per hand-off on one Linux server and about 40 on a laptop. How do you make the measurement trustworthy, and what could explain the gap?

A server forks a helper process for each request, which then runs an external tool. As the server's own heap grew to 20 GB, each fork started to take tens of milliseconds, and requests queue behind it. Explain why, and what you would change.

After a change that added a fork to a service, some log lines appear twice in the collected logs, yet never when a developer runs the service in a terminal. Explain what happens, and fix it.

A job runner forks a worker for each task and collects workers in a SIGCHLD handler that calls waitpid once. Under light load all is well, but under heavy load zombies pile up, although every worker exits. Explain why, and fix it.

You start a long job over SSH with ./job & and log out. When you log back in, the job is gone, with no error in its log. Explain what ended it, and how you would keep such a job running properly.

During every deployment, a few requests to your HTTP service fail with reset connections. The orchestrator sends SIGTERM, waits 30 seconds, then sends SIGKILL, and the service installs no signal handlers. Explain what happens to the requests in flight, and design the service's shutdown.

A daemon reloads its configuration on SIGHUP. Its handler logs with printf, then parses the new file and builds tables with malloc. Once every few weeks, right after a reload, the daemon stops responding and uses no CPU at all. Explain the hang, and redesign the reload.

Your program starts a filter such as tr as a child, with one pipe to its standard input and one from its standard output. It writes all its input first, then reads the output. With 1 KB of input it works; with 1 MB it hangs at 0 % CPU. Explain why, and fix it.

A helper running as root serves an unprivileged web worker over a Unix domain socket. The worker sends a file path, the helper checks that it lies inside /srv/uploads and replies allowed, and the worker then opens the file itself. Explain what is weak about this design, and redesign it.

Eight worker processes count requests in a shared memory page with counter++ on a volatile long. Under load the counter reports 20 % fewer requests than the access log. Explain why, fix it, and say how you would prove the fix.

A capture process produces 1920 by 1080 frames of 4 bytes per pixel at 60 frames a second, and an encoder process on the same machine consumes them. Estimate the data rate, choose the IPC, and explain how the processes coordinate so that the encoder never reads a half-written frame.