zsh and OS Kernel: Signal Propagation Order for Concurrent Background Jobs

Question

Zsh manages background processes through a built-in job control system, utilizing signal traps to handle process termination and interrupts across concurrent tasks. While the shell facilitates the execution of multiple background jobs via the & operator, the actual scheduling and signal delivery are handled by the underlying Unix kernel.

A technical uncertainty exists regarding the deterministic nature of signal delivery when a single shell signal is used to terminate multiple active background children simultaneously. Because zsh is primarily a single-threaded process, the interaction between the shell's internal job list and the kernel's process scheduler may result in inconsistent termination sequences across different operating systems, such as macOS and various Linux distributions.

Does zsh guarantee a specific order of signal propagation to background jobs based on their job ID?
How does the shell's signal handling logic interact with the kernel scheduler to ensure all concurrent processes are terminated without leaving orphaned tasks?

Tasadduq Burney · Answer

Signal Propagation Order in Zsh
No, zsh does not guarantee a deterministic signal propagation order to background jobs based on their job ID. While the shell may iterate through its internal job list sequentially when forwarding a signal, the actual delivery and execution of that signal are governed by the OS kernel's scheduler and the target process's state.

Shell Logic vs. Kernel Execution
The interaction between zsh and the kernel follows a decoupled pattern:

Shell Layer: When zsh triggers a signal to multiple background jobs (e.g., via a built-in command or a trap), it issues a series of kill() system calls. While these calls are made in a specific order within the shell's single-threaded execution, they only place the signal in the target process's pending queue.
Kernel Layer: The kernel decides when to deliver the pending signal based on the process's current execution state, signal mask, and priority. Because background jobs are concurrent, the kernel may schedule the delivery to Job #2 before Job #1, regardless of the order in which the shell issued the kill() calls.

Risk of Orphaned Processes
The shell cannot ensure all processes are terminated solely through signal propagation. A process may remain as an orphan if:

It has explicitly ignored the signal (SIG_IGN).
It has blocked the signal using sigprocmask.
It is in an uninterruptible sleep state (D state), meaning it cannot process the signal until a system call returns.

Verification Steps
To observe this behavior on your specific OS (Linux or macOS), you can use the following scoped test:
# Start two background jobs that log their PID and exit time
(while true; do sleep 1; done) & job1_pid=$!
(while true; do sleep 1; done) & job2_pid=$!

# Send a signal to the shell's process group
kill -INT -$$

# Check which process terminated first via system logs or a wrapper script

Note: Behavior may vary slightly between zsh versions (specifically 5.8+), but the fundamental reliance on the kernel scheduler for delivery timing remains constant.

Diagnostic Requirement
To provide a more precise analysis of your specific termination sequence, please specify if the background jobs are interactive shells or compiled binaries, as this changes how signals are trapped and handled.

zsh and OS Kernel: Signal Propagation Order for Concurrent Background Jobs

1 answer

Signal Propagation Order in Zsh

Shell Logic vs. Kernel Execution

Risk of Orphaned Processes

Verification Steps

Diagnostic Requirement

Your perspective belongs here.

1 question comment