Course contentsShow
← Linux
Lesson 497 of 1,8195. Process Management and SignalingFree lesson

Signal Propagation Across Namespaces

Explain the visibility of signals when processes reside in different container namespaces.

In this lesson, you will learn how the Linux PID namespace boundary acts as a strict barrier for inter-process signaling.

The Namespace Isolation Principle

Up until now, we’ve looked at signals as a way for processes to communicate globally across the system. However, in the world of containers, we use PID namespaces to isolate process trees. When you place a process in a new PID namespace, it receives a new, isolated view of the process table where it believes it is PID 1.

The kernel enforces a fundamental rule: A process cannot send a signal to a process that it cannot "see" in its own PID namespace.

How Propagation Works (or Doesn't)

If Process A (in the root/host namespace) wants to send a SIGTERM to Process B (inside a container), the kernel checks their namespaces. Because Process B lives in a nested namespace, Process A—if it is not in that same namespace or a parent namespace—cannot address it by PID.

Even if the host process somehow discovers the PID, the kernel will return an error (like ESRCH, meaning "No such process"), because the signal target does not exist within the sender's namespace context.

A Concrete Illustration

Imagine you have a container running a web server. From the host system, you can see the process with ps aux, but you are looking at it from the "outside."

# Inside the container, the app is PID 1
# From the host, the app might be PID 12345

# Sending a signal from the host:
kill -SIGTERM 12345  # This works because the host can see into child namespaces.

# Sending a signal from a *different* container:
kill -SIGTERM 12345  # This will fail with 'No such process'.

The key is that signals can propagate downwards from a parent namespace to a child namespace, but they cannot move laterally between isolated namespaces. This ensures that a process in one container cannot accidentally (or maliciously) interrupt a process in another container, keeping your application environments isolated and secure.

Key Takeaway: Signals can only be sent to processes within your own namespace or child namespaces; the namespace boundary acts as an impenetrable wall for lateral signaling.