DEV Community: Piotrek Karasinski

Signals in Linux — SIGKILL, SIGTERM, SIGCHLD and the Anatomy of a Handler

Piotrek Karasinski — Sat, 11 Jul 2026 15:13:05 +0000

You send SIGTERM to a process and it keeps running. You send SIGKILL and it vanishes instantly — but leaves an entry in the process table behind. Your SIGINT handler catches the signal sometimes and misses it other times, depending on which syscall the process happened to be sitting in. Signals look like a simple mechanism — send a number, the process reacts — but underneath they're one of the most subtle corners of the kernel interface, full of race conditions and bugs that refuse to reproduce.

This article takes signals apart: what delivery actually means, why some signals can't be caught, how SIGCHLD ties into the fork() mechanism and zombie processes, and which operations are safe inside a handler versus which ones will blow your process up.

What a signal is — from the kernel's perspective

A signal is an asynchronous notification delivered to a process by the kernel. It isn't a function call or a queued message — it's a bit set in the process structure and a (potential) interruption of its normal execution. Every process carries two key bitmasks in its descriptor: pending (signals delivered but not yet handled) and blocked (signals temporarily held off by the process).

When process A calls kill(pid_B, SIGTERM), the kernel doesn't immediately hand control to process B. It sets the SIGTERM bit in B's pending mask and returns. Actual delivery — the moment B interrupts what it was doing and runs the signal's action — happens only at the next transition from kernel mode back to user mode: typically on return from a syscall or from a timer interrupt.

This distinction between a signal being generated and being delivered is the source of most counterintuitive behavior. A process blocked in a long syscall can hold a signal pending for a while before it gets handled.

Signal dispositions: three possible reactions

For each signal, a process has one of three dispositions set, which decides what happens on delivery:

Default action (SIG_DFL) — kernel-defined behavior: terminate, terminate with a core dump, ignore, or stop.
Ignore (SIG_IGN) — the signal is discarded on delivery.
Handler — a user function registered via sigaction(), invoked in the process context at the moment of delivery.

Default actions for the most common signals look like this:

Signal	Number	Default action	Catchable?	Typical source
SIGTERM	15	Terminate	Yes	Polite shutdown request (`kill`)
SIGKILL	9	Terminate	No	Forced process kill
SIGINT	2	Terminate	Yes	Ctrl+C in a terminal
SIGSEGV	11	Core dump	Yes	Memory protection violation
SIGCHLD	17	Ignore	Yes	Child process state change
SIGSTOP	19	Stop	No	Suspend process
SIGHUP	1	Terminate	Yes	Terminal hangup / config reload

SIGKILL and SIGSTOP — why you can't catch them

Two signals — SIGKILL (9) and SIGSTOP (19) — are uncatchable by design. You can't register a handler for them, can't set them to be ignored, can't block them with a mask. The kernel handles them itself, without ever returning control to the process.

This is a deliberate design decision. If a process could intercept SIGKILL, it could ignore a termination request and become unkillable. SIGKILL is the operating system's last-resort mechanism — the guarantee that an administrator can always reclaim control over resources. Trying to install a handler fails with EINVAL:

#include <signal.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>

int main(void) {
    struct sigaction sa = {0};
    sa.sa_handler = SIG_IGN;

    if (sigaction(SIGKILL, &sa, NULL) == -1) {
        // errno == EINVAL: SIGKILL cannot have a handler
        fprintf(stderr, "sigaction(SIGKILL): %s\n", strerror(errno));
    }
    return 0;
}

The practical consequence: if a process doesn't respond to SIGTERM, it means its handler hung, it's stuck in an uninterruptible syscall (state D — uninterruptible sleep), or it's deliberately ignoring the signal. Only then do you reach for SIGKILL. But a process in state D won't respond even to SIGKILL until the syscall finishes — which is why you sometimes see processes that kill -9 won't touch.

SIGCHLD and zombie processes

This is where signals meet process management. When a child process terminates, the kernel sends SIGCHLD to the parent and — crucially — keeps a minimal entry for the child in the process table. That entry holds the exit code, resource usage statistics, and the PID. A process in this state is a zombie (state Z): it no longer runs any code, but it still occupies a slot in the process table.

The entry disappears only when the parent calls wait() or waitpid() and collects the exit code — an operation called reaping. I covered the same topic in detail from the process-creation side in the article on what fork() in Linux really does; here we look at it from the signal side.

The default disposition of SIGCHLD is to ignore it — but ignoring the signal does not reap zombies. You have to either actively call wait(), or explicitly set the disposition to SIG_IGN via sigaction() (which on Linux triggers automatic reaping), or handle SIGCHLD in a handler. A correct handler looks like this:

#include <signal.h>
#include <sys/wait.h>
#include <unistd.h>

// Reaper: collects ALL terminated child processes.
// The loop is mandatory — a single SIGCHLD can represent
// multiple terminated children (signals don't queue).
void sigchld_handler(int signo) {
    int saved_errno = errno;   // handler must preserve errno
    pid_t pid;

    while ((pid = waitpid(-1, NULL, WNOHANG)) > 0) {
        // reaped the process with this PID
    }

    errno = saved_errno;
}

int install_reaper(void) {
    struct sigaction sa = {0};
    sa.sa_handler = sigchld_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;  // restart syscalls, ignore stop/cont

    return sigaction(SIGCHLD, &sa, NULL);
}

The while loop with WNOHANG is there for a reason. Standard signals (below 32) do not queue: if three children terminate in quick succession before the handler gets a chance to run, you receive a single SIGCHLD, not three. A handler that calls waitpid() only once reaps one child and leaves two zombies behind. The loop collects everything available at once.

Async-signal-safety: what's allowed in a handler

A signal handler runs asynchronously — it can interrupt the process's main code at any point, including in the middle of a standard library call. This leads to the most common signal-handling bug: calling a function that isn't async-signal-safe.

Imagine the process is in the middle of malloc(), which is modifying internal heap structures and holding a lock. A signal arrives, the handler calls printf() — which internally also calls malloc(). The second allocation tries to take the same lock the interrupted code is holding. The result is a deadlock or heap corruption. The same applies to any function that operates on shared global state.

POSIX defines a narrow list of functions guaranteed to be async-signal-safe. The most important ones (safe vs. unsafe in a handler):

Safe in a handler	UNSAFE — never in a handler
`write()`	`printf()`, `fprintf()`
`read()`	`malloc()`, `free()`
`waitpid()`	`fopen()`, `fclose()`
`_exit()`	`exit()` (runs atexit)
`signal()`, `sigaction()`	most `stdio` functions
`kill()`	locale functions (`setlocale`)

The practical pattern: keep the handler as short as possible. Ideally it just sets a volatile sig_atomic_t flag and returns, while all the logic runs in the program's main loop after checking the flag. If the handler must log something, it uses write() directly on a descriptor, never printf().

#include <signal.h>
#include <unistd.h>

// Flag modified by the handler, read by the main loop.
// volatile: the compiler can't cache it in a register.
// sig_atomic_t: guarantees atomic read/write.
static volatile sig_atomic_t shutdown_requested = 0;

void handle_term(int signo) {
    shutdown_requested = 1;
    // optional log — write() is async-signal-safe
    const char msg[] = "SIGTERM received, shutting down\n";
    write(STDERR_FILENO, msg, sizeof(msg) - 1);
}

int main(void) {
    struct sigaction sa = {0};
    sa.sa_handler = handle_term;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    sigaction(SIGTERM, &sa, NULL);

    while (!shutdown_requested) {
        // main loop: this is where all the real work happens,
        // including resource cleanup once the flag is detected
    }

    // graceful shutdown outside the handler — anything is allowed here
    return 0;
}

SA_RESTART and interrupted syscalls

There's one more mechanism that surprises people on first contact. When a signal is delivered during a blocking syscall — say, a read() waiting for data on a socket — the syscall may be interrupted and return the error EINTR instead of completing the operation.

Without proper handling, this leads to nasty bugs: the code assumes read() will either return data or block until it can, and instead it gets EINTR and — if the programmer doesn't check for it — treats it as a fatal error. You have two options. The first is the SA_RESTART flag in sigaction(), which tells the kernel to automatically resume interrupted syscalls. The second is explicitly checking for EINTR and retrying the operation:

#include <unistd.h>
#include <errno.h>

// Wrapper resilient to signal interruption.
// Retries read() on EINTR instead of treating it as an error.
ssize_t read_retry(int fd, void *buf, size_t count) {
    ssize_t n;
    do {
        n = read(fd, buf, count);
    } while (n == -1 && errno == EINTR);
    return n;
}

Note: SA_RESTART doesn't work for all syscalls. Some of them — including those tied to waiting for events, like certain poll() variants or timer operations — return EINTR regardless of the flag. That's why defensive network code should handle EINTR explicitly anyway, even with SA_RESTART set.

Diagnostics: inspecting signals in a running process

When a process behaves strangely toward signals, you don't have to guess. The file /proc/<pid>/status shows the current signal masks in hexadecimal:

$ grep -E 'Sig|Shd' /proc/$(pgrep -n nginx)/status
SigQ:   0/31228          # queued signals / limit
SigPnd: 0000000000000000 # pending for this thread
SigBlk: 0000000000000000 # blocked (mask)
SigIgn: 0000000000001000 # ignored
SigCgt: 0000000180014a07 # caught (have a handler)

Each bit corresponds to one signal (bit 0 = signal 1). The SigCgt mask tells you which signals the process handles with its own handler — useful when you want to verify an application actually responds to SIGHUP (config reload) before sending it in production.

To trace signal delivery in real time, use strace with a signal filter. It shows the exact moment of delivery and whether the handler was invoked — a tool I cover in the article on reading syscalls with strace when the stack trace lies:

$ strace -e trace=signal -p <pid>
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=4821} ---
rt_sigreturn({mask=[]})  = 202
# you can see SIGTERM delivered and the return from the handler

Summary

Signals in Linux aren't a simple "send a number, the process reacts" mechanism. They're an asynchronous interface with three layers of subtlety: the distinction between generation and delivery, the constraints on what you're allowed to do in a handler, and the non-queuing of standard signals. The most common bugs come from ignoring those three things — a handler calling printf(), a reaper without a while loop, network code that doesn't handle EINTR.

The rule of thumb: treat a signal handler like a hardware interrupt routine. The less you do in it, the fewer things can go wrong. Set a flag, return, handle the rest in the main loop — and never assume one signal means one event.

Originally published on devmindset.dev — Linux internals, systems programming, and the self-taught developer mindset.

Related deep-dives:

Building an MCP Server in Python — Architecture, FastMCP, and Production Code

Piotrek Karasinski — Fri, 03 Jul 2026 09:42:55 +0000

I run my blog, devmindset.dev, through a custom MCP server.**. Publishing posts, updating SEO metadata, assigning categories — all of it goes through a protocol that, a year ago, didn't exist in production form. So I'm not writing about MCP from the documentation's point of view, but from the point of view of someone who stood up a working server and operates it daily. This isn't another "hello world" — it's protocol architecture, deliberate design decisions, and production code in Python.

The Model Context Protocol (MCP) is an open standard introduced by Anthropic in November 2024, now developed under the Agentic AI Foundation (Linux Foundation). The stable spec is dated 2025-11-25, and the largest revision since launch lands on July 28, 2026 — more on that shortly, because it changes how you design transport. But let's start with the question most tutorials skip: what does this protocol actually solve?

What MCP actually solves

The problem MCP addresses is combinatorial. You have M LLM applications (Claude Desktop, Cursor, VS Code, ChatGPT) and N external systems (a database, GitHub, an internal API, WordPress). Without a shared standard, every pair needs a bespoke integration — that's M×N implementations, each with its own format, its own auth, its own maintenance burden. MCP collapses that into M+N: you write the server once, and every compliant client can discover and use it without a line of code on its side.

Mechanically, MCP sits on JSON-RPC 2.0 and defines three roles. The host is the LLM application that coordinates everything. The client is instantiated by the host — one client per server. The server provides context and capabilities. It's deliberately modeled on the Language Server Protocol: just as LSP standardized language support across editors, MCP standardizes wiring tools and data into the AI ecosystem.

And here's the first misconception to defuse: MCP is not "function calling." Function calling is a single-vendor mechanism — you define functions in your code and one specific model invokes them. MCP is a transport protocol and a negotiation layer: the server advertises its capabilities, the client discovers them at runtime, and versions are negotiated at initialization. Function calling lives inside one application; an MCP server is reusable across any host.

Three primitives: tools, resources, and prompts

An MCP server exposes capabilities through three primitives. Conflating them is the most common design mistake — each has a different contract and a different use.

Primitive	What it is	Who controls it	Use for
Tool	Executable action with validation and logic	Model (calls when needed)	Side-effecting operations, complex logic
Resource	Read-only data under a URI template	Application / host	Static or semi-static context
Prompt	Reusable template	User (selects deliberately)	Repeatable, structured instructions

Rule of thumb: Tool when you need input validation and business logic ("create a post with title X and status Y"). Resource when you expose data under a simple parameter ("the contents of document Z"). Prompt when you hand the user a ready-made, parameterized scenario. In practice, most servers start and end with tools — the rest is context optimization.

Transport: stdio vs Streamable HTTP

MCP defines two transports, and choosing between them is the first architectural decision when building an MCP server.

Dimension	stdio	Streamable HTTP
Location	Local, same machine	Remote, over HTTPS
Run model	Host subprocess	Network service
Clients	One (process)	Many concurrently
Authorization	Inherited from OS	OAuth 2.1 / OIDC
Use for	CLI tools, local integrations	Production servers, SaaS

And here's the change most material hasn't caught up to yet. The 2026-07-28 revision (currently a release candidate) removes the protocol-level session — the Mcp-Session-Id header is gone (SEP-2567). Protocol version, client info, and capabilities now travel in _meta on every request, and a new server/discover method lets the client fetch server capabilities on demand. The practical consequence: any request can land on any server instance. The sticky routing and shared session stores that horizontal deployments used to need are no longer required at the protocol layer.

This doesn't mean your application has to be stateless. A server that needs state across calls does what HTTP APIs have always done: mint an explicit handle (say, a basket_id) from one tool and have the model pass it back as an ordinary argument on later calls. So design for stateless transport from the start — it's the direction the protocol is heading, and the cheaper path to scale.

A minimal production MCP server — FastMCP

The official Python SDK ships FastMCP — a high-level framework that generates the input schema from signatures and docstrings, integrates Pydantic validation, and registers tools with a decorator. Below is not a "hello world" but a skeleton with everything that separates a toy from production code: a Pydantic model for validation, behavior annotations, async I/O, error handling, and full typing.

from __future__ import annotations

import os
import httpx
from pydantic import BaseModel, Field, ConfigDict
from mcp.server.fastmcp import FastMCP

# Name the server per the {service}_mcp convention
mcp = FastMCP("weather_mcp")

API_BASE = "https://api.example-weather.com/v1"


class ForecastInput(BaseModel):
    """Input validation for a forecast query."""
    model_config = ConfigDict(
        str_strip_whitespace=True,
        extra="forbid",          # reject unknown fields
    )

    city: str = Field(..., description="City name, e.g. 'Wrocław'",
                      min_length=1, max_length=100)
    days: int = Field(default=3, description="Forecast horizon in days",
                      ge=1, le=14)


def _handle_error(e: Exception) -> str:
    """Consistent, actionable error messages for the model."""
    if isinstance(e, httpx.HTTPStatusError):
        code = e.response.status_code
        if code == 404:
            return "Error: city not found. Check the spelling of the name."
        if code == 429:
            return "Error: rate limit exceeded. Wait before retrying."
        return f"Error: API returned status {code}."
    if isinstance(e, httpx.TimeoutException):
        return "Error: request timed out. Please try again."
    return f"Error: unexpected exception: {type(e).__name__}"


@mcp.tool(
    name="get_forecast",
    annotations={
        "title": "Get weather forecast",
        "readOnlyHint": True,      # does not modify state
        "openWorldHint": True,     # reaches an external API
    },
)
async def get_forecast(params: ForecastInput) -> str:
    """Return a weather forecast for a city.

    Args:
        params: validated input (city, days).
    Returns:
        str: a formatted forecast or an actionable error message.
    """
    api_key = os.environ.get("WEATHER_API_KEY")
    if not api_key:
        return "Config error: WEATHER_API_KEY is missing from the environment."

    try:
        async with httpx.AsyncClient(timeout=10.0) as client:
            resp = await client.get(
                f"{API_BASE}/forecast",
                params={"q": params.city, "days": params.days},
                headers={"Authorization": f"Bearer {api_key}"},
            )
            resp.raise_for_status()
            data = resp.json()
    except Exception as e:
        return _handle_error(e)

    lines = [f"Forecast for {params.city} ({params.days} days):"]
    for day in data["forecast"]:
        lines.append(f"  {day['date']}: {day['temp_c']}°C, {day['condition']}")
    return "\n".join(lines)


if __name__ == "__main__":
    mcp.run()   # stdio transport (default)

Several things here are deliberate. The Pydantic model with extra="forbid" rejects unknown fields instead of silently ignoring them. The decorator annotations (readOnlyHint, openWorldHint) are signals to the host. All I/O is async. And the secret comes from an environment variable, not the code — which I'll come back to under security.

Error handling that helps the model

Look at the _handle_error function above. This isn't cosmetics. An error message in an MCP server is read by the model, not by a human staring at logs — and it decides whether the model recovers the call sensibly or gets stuck. "Error 404" says nothing; "city not found, check the spelling" tells the model what to do next. Treat every message as a recovery instruction, not a log line.

It's the same discipline as debugging as a process of deduction rather than guessing — a precise signal instead of noise shortens the path to the cause. The difference is that here the recipient of the signal is a model planning its next step.

Security: why tool descriptions are untrusted

The MCP spec says it plainly: tools represent arbitrary code execution and must be treated with appropriate caution. Moreover — descriptions of tool behavior, including annotations, are untrusted unless they come from a trusted server. This is not a formality. A malicious server can smuggle instructions into a tool description or into a tool's result that the model treats as a command — that's prompt injection via tool output.

The consequences for you as a server author are concrete. Keep secrets in environment variables, never in code or descriptions (you can see it above — WEATHER_API_KEY from os.environ). For remote transport use OAuth 2.1 / OIDC — the 2026-07-28 revision aligns authorization more closely with OAuth and OpenID Connect, and the Enterprise-Managed Authorization extension is now stable. Validate every input with Pydantic, because the model can pass anything. And set annotations honestly:

Annotation	Meaning	Example
`readOnlyHint`	Tool does not modify state	Fetch a forecast, read a post
`destructiveHint`	Irreversible operation	Delete a resource
`idempotentHint`	Repeating changes nothing	Set a value to X
`openWorldHint`	Reaches external systems	Query a weather API

The host builds user-consent flows on these signals. A lied-about annotation (say, readOnlyHint on a tool that deletes data) isn't just bad code — it breaks the security contract the entire MCP trust model rests on.

State, concurrency, and scaling

A production server handles many clients at once, and every tool does I/O — a call to an API, a database, a disk. That's why all the code is async (async def, httpx.AsyncClient): one process serves many concurrent calls without blocking, because while waiting on a network response the event loop switches to another task.

This is exactly the same I/O-scaling problem solved underneath by epoll and io_uring, when the event loop isn't enough — the "one thread per connection" model doesn't scale indefinitely. An MCP server over Streamable HTTP sits on the same layer: async isn't an ornament, it's the condition for serving many clients on one instance. And thanks to the 2026-07-28 stateless core, horizontal scaling comes down to standing up more instances behind a load balancer — no sticky sessions.

# Local — stdio (default)
mcp.run()

# Remote — Streamable HTTP, scales horizontally
mcp.run(transport="streamable_http", port=8000)

Conclusion

Building an MCP server that isn't a toy comes down to a few deliberate decisions: transport choice (stdio locally, Streamable HTTP in production), the right primitive (tool vs resource vs prompt), Pydantic validation, actionable errors, secrets in the environment, and honest annotations. FastMCP takes the boilerplate off your hands, but architecture and security stay on yours.

One more thing, and it's fresh: design for statelessness. The 2026-07-28 revision makes transport sessionless by default, and that's the cheapest path to scale the protocol has ever offered. An MCP server written today around explicit state handles instead of sessions will survive that change without a rewrite. This is the first post in a series on MCP — the next ones go deeper into security and advanced patterns.

Originally published on devmindset.dev — Linux internals, systems programming, and the self-taught developer mindset.

Related deep-dives:

malloc internals — Why free() Doesn't Return Memory to the System

Piotrek Karasinski — Thu, 02 Jul 2026 06:00:00 +0000

Why Your Process's RSS Grows and Doesn't Shrink

The classic moment of confusion: a program allocates 2 GB, processes the data, frees everything via free() — and htop still shows 2 GB of resident memory (RSS). A leak? No. It's the designed behavior of the allocator, which most developers mistake for a bug because they don't understand what malloc() and free() actually do under the hood.

In the vast majority of cases, free() does not return memory to the operating system. It returns it to the allocator — the intermediate layer between your code and the kernel that manages memory pools to avoid costly syscalls on every allocation. Understanding this layer is the difference between "we have a memory leak" and "that's arena fragmentation, RSS won't shrink, but it isn't a leak."

This article dissects the internals of malloc in glibc: arenas, bins, chunks, the brk vs mmap boundary, the mechanics of fragmentation, and — crucial for production decisions — when jemalloc or tcmalloc beats the default glibc allocator.

The Intermediate Layer: Why We Don't Call the Kernel Directly

The kernel manages memory at page granularity (usually 4 KB). If every malloc(16) required a syscall to the kernel, the cost would be absurd — a syscall is ~100–500 ns, and a typical program does millions of allocations. The allocator solves this by requesting memory from the kernel in bulk and dividing it into small pieces in userspace.

Two syscalls supply memory from the kernel:

Mechanism	Action	Use in glibc malloc
`brk` / `sbrk`	Moves the data segment boundary (program break)	Small allocations (< 128 KB), main arena
`mmap`	Maps anonymous pages anywhere in the address space	Large allocations (≥ 128 KB) and thread arenas

# See both mechanisms in action — strace on a simple program
$ strace -e trace=brk,mmap ./program 2>&1 | head
brk(NULL)                = 0x55a3c2a00000        # current program break
brk(0x55a3c2a21000)      = 0x55a3c2a21000        # arena extension (132 KB)
mmap(NULL, 2101248, PROT_READ|PROT_WRITE, ...)   # large allocation (2 MB)
                         = 0x7f3a8c000000

The key threshold is M_MMAP_THRESHOLD (default 128 KB). Allocations below it come from the arena managed by brk; above it — directly via memory mapping (mmap). This distinction has fundamental consequences for whether memory ever returns to the system.

Anatomy of a Chunk — How malloc Remembers Sizes

When you call malloc(100), you get a pointer to 100 bytes — but the allocator reserved more. Every memory block is a chunk with a metadata header just before the returned pointer:

/* Simplified chunk structure in glibc (ptmalloc2) */
struct malloc_chunk {
    size_t      prev_size;  /* size of the previous chunk, IF free */
    size_t      size;       /* size of this chunk + 3 flag bits */

    /* The fields below are used ONLY when the chunk is free: */
    struct malloc_chunk *fd;  /* forward pointer in the free list */
    struct malloc_chunk *bk;  /* backward pointer in the free list */
};

/* The three lowest bits of 'size' are flags (chunks 8B-aligned): */
/* PREV_INUSE     (0x1) — whether the previous chunk is in use     */
/* IS_MMAPPED     (0x2) — whether the chunk comes from mmap         */
/* NON_MAIN_ARENA (0x4) — whether the chunk belongs to a thread arena */

A clever trick: when a chunk is in use, the fd/bk fields aren't needed, so that area holds user data. When the chunk is free, those same bytes store list pointers. This is why a use-after-free that overwrites a freed chunk corrupts the allocator's lists — it writes over fd/bk, which on the next allocation leads to a write to an arbitrary address (the classic fastbin dup exploitation vector).

Bins — The Structure for Managing Free Chunks

Freed chunks aren't immediately returned to the system. They go into bins — lists of free chunks grouped by size, so the next malloc() can quickly find a matching block. glibc maintains several bin categories with different characteristics:

Bin type	Chunk size	Characteristics
Fast bins	16–160 B (10 bins)	LIFO, no coalescing — fastest, single-linked
Tcache	per-thread, 24–1032 B	Per-thread cache (glibc 2.26+), lock-free
Small bins	< 512 B (62 bins)	FIFO, exact size, double-linked
Large bins	≥ 512 B	Sorted, size ranges, best-fit
Unsorted bin	any	Intermediate buffer before classification

Tcache (thread-local caching) is the most important optimization of recent years: each thread has its own pool of recently freed chunks, accessible without taking the arena lock. This dramatically speeds up multithreaded allocations, but also introduced new attack vectors (tcache poisoning).

Why free() Doesn't Return Memory

When you free a chunk, the allocator runs a sequence:

Checks if the chunk fits in the tcache → if so, drops it there (the fastest path)
If small → fast bin or small bin
Tries to coalesce with adjacent free chunks to counteract fragmentation
Only if a large, contiguous free area grows at the top of the arena (top chunk) — the allocator may call sbrk with a negative argument or malloc_trim() to return memory

The critical condition: memory returns to the system only when the free area is at the very end of the arena and exceeds the threshold (M_TRIM_THRESHOLD, default 128 KB). If a live chunk sits behind the freed area, brk can't retreat — the memory stays reserved, though free. This is fragmentation, not a leak.

#include <stdlib.h>
#include <malloc.h>

int main(void) {
    /* Allocate 1000 blocks of 1 KB */
    void *blocks[1000];
    for (int i = 0; i < 1000; i++)
        blocks[i] = malloc(1024);

    /* Free all the EVEN ones — a fragmentation checkerboard */
    for (int i = 0; i < 1000; i += 2)
        free(blocks[i]);

    /* RSS stays high: free chunks interleave with live ones,
       brk can't retreat because live chunks block the arena's end */

    /* Explicitly force memory return to the system */
    malloc_trim(0);   /* return everything possible from the arena's end */

    return 0;
}

mmap vs brk — Why Large Allocations Are Different

Allocations above M_MMAP_THRESHOLD go directly via mmap and have a fundamentally different return profile. Each such allocation is a separate mapping that free() immediately returns to the system via munmap — because it's an independent region, not part of a shared arena.

Property	`brk` arena (small)	`mmap` (large ≥128 KB)
Return to OS on free()	Rarely (only from arena's end)	Immediately (munmap)
Allocation cost	Low (usually no syscall)	High (syscall + page fault)
Fragmentation	Possible (shared arena)	None (isolated mappings)
Initialization	Memory may contain garbage	Always zeroed (kernel guarantees)

Hence the counterintuitive effect: a program doing many large allocations may have more stable RSS than one with a million small ones, because the large ones return to the system immediately while the small ones stay trapped in the arena. The threshold is also dynamic — glibc increases it when it detects the program freeing large blocks, to avoid costly mmap/munmap cycles.

Arenas — Multithreaded Scaling

In a multithreaded program, if all threads competed for a single arena, the lock on it would be a bottleneck. glibc solves this with multiple arenas: the main arena (on brk) plus additional thread arenas (on mmap), each with its own lock.

# The number of arenas is capped — default 8 × core count (64-bit)
$ echo $((8 * $(nproc)))
64

# Control via an environment variable
$ MALLOC_ARENA_MAX=2 ./program
# Limiting arenas reduces memory usage (fewer separate pools)
# at the cost of potential lock contention with many threads

# Diagnostics of all arenas' state
$ MALLOC_STATS=1 ./program 2>&1 | tail -20

The trade-off is direct: more arenas = less lock contention, but more fragmented, unreturned memory (each arena holds its own free chunks). For multithreaded, RSS-sensitive applications, MALLOC_ARENA_MAX=2 is a common first optimization shot. This also explains why the same program uses more memory on a 64-core machine than a 4-core one.

Alternative Allocators — Measurement, Not Ideology

The default ptmalloc2 in glibc is a general-purpose compromise. For specific workloads, specialized allocators offer a measurable advantage.

Allocator	Strength	Typical use
ptmalloc2 (glibc)	Universal, always available	Default, most applications
jemalloc	Low fragmentation, predictable RSS, profiling	Databases, long-running servers (Redis, FB)
tcmalloc (Google)	Very fast small allocations, great multithreaded	Google apps, allocation-intensive
mimalloc (Microsoft)	Newest, great speed/fragmentation balance	New projects, .NET runtime

# Swap the allocator WITHOUT recompilation — via LD_PRELOAD
$ LD_PRELOAD=/usr/lib/libjemalloc.so.2 ./server
# Same binary, different allocator — instant benchmark

# Compare RSS under load (same workload, different allocators)
$ /usr/bin/time -v ./server 2>&1 | grep "Maximum resident"
    Maximum resident set size (kbytes): 524288   # glibc
    Maximum resident set size (kbytes): 312456   # jemalloc — ~40% less

# Permanent swap: link at compile time
$ gcc program.c -ljemalloc -o program

The swap mechanism is LD_PRELOAD overriding the malloc/free symbols from libc — the same interposition mechanism that powers AddressSanitizer. Practical rule: jemalloc when you're fighting fragmentation and RSS on a long-running server, tcmalloc when the bottleneck is small-allocation throughput across many threads. Always, however, measure first — for many applications the default glibc is sufficient, and swapping is premature optimization.

Diagnostics — Tools

Tool	Use
`strace -e brk,mmap`	Which memory syscalls the program actually makes
`MALLOC_STATS=1`	glibc arena and bin statistics on exit
`malloc_info()`	Programmatic dump of allocator state (XML)
`valgrind --tool=massif`	Heap usage profile over time (heap profiler)
`jemalloc + jeprof`	Allocation profiling with function attribution
`/proc/<pid>/smaps`	Detailed RSS breakdown by mapping (heap, mmap, anon)
`cat /proc/<pid>/status`	VmRSS vs VmData — resident vs reserved

Conclusion: The Allocator as a Layer You Must Understand

malloc and free aren't thin wrappers over the kernel — they're a sophisticated memory management layer with arenas, bins, chunks, and anti-fragmentation strategies. An engineer who understands this layer doesn't panic at high RSS after free(), knows when it's fragmentation versus a real leak, and can deliberately match the allocator to the workload's profile.

The key understandings: free() returns memory to the allocator, not the system; the brk vs mmap boundary at 128 KB determines whether memory ever returns; tcache and multiple arenas speed up multithreading at the cost of RSS; and chunk metadata interleaves with data, which makes use-after-free a corruption vector. This knowledge turns "mysterious memory growth" into a predictable, measurable, and controllable aspect of the system.

RSS that doesn't drop after free() is most often not a bug in your code — it's the allocator doing exactly what it was designed to do. The question isn't "why didn't it free," but "is this fragmentation, or am I actually holding live references."

Anatomy of a Segfault — From MMU Through Kernel to gdb Core Dump — use-after-free and chunk corruption from the page-fault angle
ELF and Dynamic Linking — What Happens Before main() Runs — LD_PRELOAD as the allocator swap mechanism
mmap — When Memory-Mapped I/O Beats read() and write() — mmap for large anonymous allocations
What fork() in Linux Really Does Under the Hood — copy-on-write and sharing heap pages

Originally published on devmindset.dev — Linux internals, systems programming, and the self-taught developer mindset.

cgroups v2 as a Native Runtime Isolation Primitive — No Docker Required

Piotrek Karasinski — Wed, 01 Jul 2026 06:00:00 +0000

The Overhead Tax of Container Abstraction

Every time a team reaches for Docker to isolate a background service—a scheduled job, a data pipeline, a monitoring daemon—it pays an overhead tax. The container runtime (containerd, runc) must initialize a namespaced environment, mount overlay filesystems, and manage network virtualization, even when the only requirement is CPU throttling and memory capping for a single process.

cgroups v2 (Control Groups version 2), unified in Linux 4.5 and enabled by default on most modern distributions including Arch Linux since kernel 5.8+, provides that isolation primitive natively—with zero daemon overhead, no image layers, no OCI spec compliance ceremony.

This article dissects the operational architecture of the cgroups v2 unified hierarchy, its integration with systemd's transient unit model, and programmatic control via Python—delivering the isolation contract without the abstraction tax.

cgroups v2: Architectural Shift from v1

The fundamental flaw of cgroups v1 was its fragmented, per-controller hierarchy. CPU limits lived in /sys/fs/cgroup/cpu/, memory limits in /sys/fs/cgroup/memory/—independent trees that could produce conflicting resource assignments and made atomic process migration across controllers operationally fragile.

cgroups v2 enforces a single, unified hierarchy rooted at /sys/fs/cgroup/. All controllers—cpu, memory, io, pids—operate within one coherent tree. The key architectural invariant: a process can belong to exactly one cgroup.

Unified Hierarchy Verification

# Verify cgroups v2 is the active mode
$ mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

# Inspect available controllers on root cgroup
$ cat /sys/fs/cgroup/cgroup.controllers
cpuset cpu io memory hugetlb pids rdma misc

If the output shows cgroup2 as the filesystem type and a unified set of controllers, the system is fully migrated. On hybrid systems, the cgroup_no_v1=all kernel parameter forces exclusive v2 mode.

Direct Cgroup Lifecycle Management

Cgroup management at its core is filesystem manipulation. Creating a cgroup means creating a directory; assigning a process means writing its PID to cgroup.procs; constraining resources means writing values to controller-specific interface files.

Creating and Configuring a Cgroup

# Create a cgroup for an isolated workload
$ mkdir /sys/fs/cgroup/devmindset-worker

# Enable CPU and memory controllers on this cgroup
$ echo "+cpu +memory" > /sys/fs/cgroup/devmindset-worker/cgroup.subtree_control

# Cap CPU utilization: 20% of one core (quota/period in microseconds)
$ echo "20000 100000" > /sys/fs/cgroup/devmindset-worker/cpu.max

# Hard memory limit: 256 MiB
$ echo $((256 * 1024 * 1024)) > /sys/fs/cgroup/devmindset-worker/memory.max

# Assign current shell process to the cgroup
$ echo $$ > /sys/fs/cgroup/devmindset-worker/cgroup.procs

The cpu.max interface accepts $QUOTA $PERIOD pairs, directly mapping to CFS (Completely Fair Scheduler) bandwidth throttling. Any process inside this cgroup consuming more than 20ms per 100ms window will be throttled at the scheduler level—no userspace daemon required.

Systemd Integration: Transient Units as Isolation Primitive

For production workloads on systemd-based systems, systemd-run is the idiomatic abstraction over cgroups v2. It spawns a process inside a transient systemd scope or service unit, inheriting the systemd cgroup delegation model.

# Launch an isolated process with resource constraints via transient unit
$ systemd-run \
    --scope \
    --unit=devmindset-worker \
    --property=CPUQuota=20% \
    --property=MemoryMax=256M \
    --property=IOWeight=10 \
    /usr/bin/python3 /opt/workers/pipeline_runner.py

# Inspect live resource accounting
$ systemctl status devmindset-worker.scope
$ cat /sys/fs/cgroup/system.slice/devmindset-worker.scope/cpu.stat

The --scope flag creates a transient unit scoped to the calling session, while --service creates a persistent transient service with full systemd lifecycle management. The IOWeight property maps to the CFQ/BFQ I/O scheduler weight, providing proportional I/O bandwidth allocation.

Programmatic Control via Python

For dynamic workload management—spinning up isolated workers at runtime, adjusting quotas based on telemetry, implementing backpressure mechanisms—Python's pathlib provides clean, idiomatic access to the cgroupfs interface.

from __future__ import annotations

import os
import subprocess
from pathlib import Path
from typing import Final

# Micro-Rationale: Using pathlib.Path for type-safe filesystem operations
# over raw string concatenation. O(1) path construction, zero external deps.
CGROUP_ROOT: Final[Path] = Path("/sys/fs/cgroup")

class CgroupV2Controller:
    """Manages a single cgroups v2 hierarchy for process isolation.

    Enforces CPU quota and memory hard limits on a named cgroup.
    Implements context manager protocol for deterministic cleanup.
    """

    def __init__(
        self,
        name: str,
        cpu_quota_percent: int = 25,
        memory_max_mib: int = 256,
    ) -> None:
        if not 1 <= cpu_quota_percent <= 100:
            raise ValueError(f"cpu_quota_percent must be in [1, 100], got {cpu_quota_percent}")
        if memory_max_mib < 16:
            raise ValueError(f"memory_max_mib must be >= 16 MiB, got {memory_max_mib}")

        self.name = name
        self._cpu_quota_percent = cpu_quota_percent
        self._memory_max_bytes = memory_max_mib * 1024 * 1024
        self._cgroup_path = CGROUP_ROOT / name

    def _write(self, interface: str, value: str) -> None:
        """Writes a value to a cgroup interface file."""
        target = self._cgroup_path / interface
        try:
            target.write_text(value, encoding="utf-8")
        except PermissionError as exc:
            raise PermissionError(
                f"Insufficient privileges to write to {target}. "
                "Run as root or with CAP_SYS_ADMIN."
            ) from exc
        except OSError as exc:
            raise OSError(f"Failed to write '{value}' to {target}: {exc}") from exc

    def create(self) -> "CgroupV2Controller":
        """Creates the cgroup directory and configures resource limits."""
        try:
            self._cgroup_path.mkdir(parents=False, exist_ok=False)
        except FileExistsError:
            raise FileExistsError(f"Cgroup '{self.name}' already exists at {self._cgroup_path}")

        self._write("cgroup.subtree_control", "+cpu +memory")

        # CPU quota: $QUOTA $PERIOD in microseconds (CFS bandwidth throttling)
        period_us = 100_000
        quota_us = int(period_us * self._cpu_quota_percent / 100)
        self._write("cpu.max", f"{quota_us} {period_us}")

        # Memory hard limit — OOM killer fires at this threshold
        self._write("memory.max", str(self._memory_max_bytes))
        return self

    def assign_pid(self, pid: int) -> None:
        """Moves a process into this cgroup by writing to cgroup.procs."""
        try:
            os.kill(pid, 0)
        except ProcessLookupError:
            raise ProcessLookupError(f"No process with PID {pid} found.")
        self._write("cgroup.procs", str(pid))

    def assign_current_process(self) -> None:
        """Moves the calling process into this cgroup."""
        self.assign_pid(os.getpid())

    def destroy(self) -> None:
        """Removes the cgroup directory. All processes must be migrated first."""
        procs = (self._cgroup_path / "cgroup.procs").read_text().strip()
        if procs:
            raise OSError(
                f"Cannot destroy cgroup '{self.name}': "
                f"PIDs still assigned: {procs.splitlines()}"
            )
        self._cgroup_path.rmdir()

    def __enter__(self) -> "CgroupV2Controller":
        return self.create()

    def __exit__(self, *_: object) -> None:
        try:
            self.destroy()
        except OSError:
            pass  # Best-effort cleanup; log in production

# --- Usage ---
if __name__ == "__main__":
    worker_proc = subprocess.Popen(["/usr/bin/python3", "/opt/workers/cpu_intensive_task.py"])

    with CgroupV2Controller(
        name="devmindset-worker",
        cpu_quota_percent=20,
        memory_max_mib=256,
    ) as cgroup:
        cgroup.assign_pid(worker_proc.pid)
        worker_proc.wait()

Overhead Comparison: Docker vs. Direct cgroups v2

Dimension	Docker (`runc`)	Direct cgroups v2
Runtime daemon	`containerd` + `dockerd`	None
Process start latency	~80–150ms (OCI init)	< 1ms (mkdir + write)
Filesystem isolation	OverlayFS mount required	Not applicable
Network namespace	Virtual NIC + iptables rules	Not applicable
Memory overhead	~15–30 MiB per container	Zero
Kernel interface	Indirect (runc → seccomp → cgroup)	Direct
Appropriate use case	Full application isolation, portability	Single-process resource capping

Conclusion: Choosing the Right Isolation Primitive

cgroups v2 is not a Docker alternative—it is the mechanism Docker is built on. Reaching for it directly means operating at the right abstraction level for the problem at hand. On a hardened Arch Linux system running a set of long-lived workers, background scrapers, or ML inference daemons, a 150-line Python controller and three systemd-run flags deliver full runtime isolation without the operational surface of a container orchestration stack.

The engineers who understand the kernel primitives their tools are built on will always debug faster, profile more accurately, and architect more efficiently than those who interact exclusively through abstraction layers.

Originally published on devmindset.dev — Linux internals, systems programming, and the self-taught developer mindset.

Related deep-dives:

strace as a Debugging Primitive — When the Stack Trace Lies

Piotrek Karasinski — Tue, 30 Jun 2026 18:29:04 +0000

Your logs tell you what your code thinks it did. Your stack trace tells you where the code believed it was. strace tells you what the kernel actually did — every openat(), every read(), every connect() that returned -1 while your application swallowed the error and kept lying to you. When the gap between intent and reality is the bug, re-reading the source will not close it. You have to observe the boundary where userspace ends and the kernel begins.

Most engineers know strace -p <pid> as a panic button. Few actually read the output, and fewer reach for -f, -c, or -k when it counts. That gap is the difference between staring at a wall of syscalls and extracting a root cause in ninety seconds. Treating strace as a first-class instrument is a direct extension of hypothesis-driven debugging methodology: you form a precise claim about what the process is doing and let the evidence confirm or kill it.

What strace actually observes

strace is built on ptrace(2), the same kernel facility debuggers use. It attaches to a target and stops it on every transition across the syscall boundary — once on entry, once on exit — reading the registers to decode the syscall number, its arguments, and its return value. That is the whole model, and it explains the cost: every syscall now pays for two extra context switches into the tracer. On a syscall-heavy workload the target can slow by an order of magnitude. This is not a footnote — it is the reason strace belongs in diagnosis, never in a hot path or a latency-sensitive production service.

Reading a trace line — the part nobody teaches

Every line has the same shape: syscall(arguments) = return_value. The return value is where the truth lives. A successful call returns a file descriptor, a byte count, or 0; a failure returns -1 followed by the symbolic errno and its description. That errno is the signal you came for.

openat(AT_FDCWD, "/etc/app/config.yaml", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/app/config.yaml", O_RDONLY) = 3
read(3, "host: 127.0.0.1\nport: 6379\n", 4096) = 27
connect(4, {sa_family=AF_INET, sin_port=htons(6379), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)

Four lines, two findings, zero guesswork: the app probed a config path that does not exist before falling back to the real one, and the Redis connection was refused outright. No log statement told you either fact — the syscalls did. The failure worth memorising is EFAULT: it means a syscall received a pointer to memory the process does not own. That is the same class of bad-address access which, followed to its conclusion by the MMU and the kernel, produces a segmentation fault.

The flags that separate signal from noise

-f — follow forks and threads. The moment a process calls fork() or spawns a worker pool, an unadorned trace goes blind to the children. Almost every real service needs this flag.
-e trace=… — filter by class instead of drowning. -e trace=network, -e trace=%file, -e trace=memory cut the stream to the syscalls you care about.
-c — aggregate instead of stream. Produces a summary table of time, call count, and errors per syscall. This is your profiler the moment you suspect a process is syscall-bound.
-T / -tt — time spent inside each syscall / absolute timestamps. Together they turn "it's slow" into "it spends 600 ms in fsync".
-y / -yy — decode descriptors, so read(3, …) becomes read(3</usr/share/app/config.yaml>, …) and sockets show their endpoints.
-k — attach a userspace stack trace to each syscall, bridging "which syscall" to "which line of code".
-s N — raise the printed string length (the default truncates payloads).

The summary mode also answers "why is this slow?" without a dedicated profiler. Run any command under strace -f -c and the table ranks syscalls by cumulative time — the same technique that turns a sluggish terminal into a fixable list of offending stat() and openat() calls when you profile shell startup and .bashrc performance.

From raw trace to an actionable summary

Reading -c output by eye is fine once. When you want it in CI, in a regression gate, or aggregated across runs, parse it. The wrapper below runs a command under strace -f -c, captures the summary from stderr, parses it into typed records, and returns the syscalls that dominate time. It handles the obvious failure modes — strace missing, the target hanging, a malformed table — instead of assuming the happy path.

from __future__ import annotations

import shutil
import subprocess
from dataclasses import dataclass
from typing import Final

_HEADER_TOKENS: Final[tuple[str, ...]] = ("seconds", "calls", "syscall")

@dataclass(frozen=True, slots=True)
class SyscallStat:
    name: str
    seconds: float
    calls: int
    errors: int

    @property
    def usec_per_call(self) -> float:
        return (self.seconds / self.calls) * 1_000_000 if self.calls else 0.0

class StraceError(RuntimeError):
    """Raised when strace cannot be run or its summary cannot be parsed."""

def profile_syscalls(cmd: list[str], *, timeout: float = 30.0) -> list[SyscallStat]:
    """Run *cmd* under ``strace -f -c`` and return per-syscall stats, busiest first.

    Raises:
        StraceError: strace is missing, the command times out, or the summary
            table cannot be located in strace's stderr.
    """
    if not cmd:
        raise StraceError("empty command")
    if shutil.which("strace") is None:
        raise StraceError("strace is not installed or not on PATH")

    try:
        proc = subprocess.run(
            ["strace", "-f", "-c", "--", *cmd],
            capture_output=True,
            text=True,
            timeout=timeout,
            check=False,  # the traced command may legitimately exit non-zero
        )
    except subprocess.TimeoutExpired as exc:
        raise StraceError(f"traced command exceeded {timeout:.0f}s") from exc

    return _parse_summary(proc.stderr)

def _parse_summary(stderr: str) -> list[SyscallStat]:
    lines = stderr.splitlines()
    header = next(
        (i for i, ln in enumerate(lines) if all(t in ln for t in _HEADER_TOKENS)),
        None,
    )
    if header is None:
        raise StraceError("no summary table found; was -c passed to strace?")

    stats: list[SyscallStat] = []
    for line in lines[header + 1:]:
        if not line.strip() or line.lstrip().startswith("-"):
            continue
        if "total" in line:
            break  # the total row terminates the table
        cols = line.split()
        if len(cols) = 6 and cols[4].isdigit() else 0
        except (ValueError, IndexError):
            continue  # skip anything that is not a data row
        stats.append(SyscallStat(name=cols[-1], seconds=seconds, calls=calls, errors=errors))

    if not stats:
        raise StraceError("summary table present but no rows could be parsed")
    return sorted(stats, key=lambda s: s.seconds, reverse=True)

if __name__ == "__main__":
    import sys

    if len(sys.argv) < 2:
        raise SystemExit("usage: profile.py COMMAND [ARGS...]")

    for stat in profile_syscalls(sys.argv[1:]):
        marker = "  (has errors)" if stat.errors else ""
        name = stat.name.ljust(18)
        calls = str(stat.calls).rjust(8)
        print(f"{name}{stat.seconds:9.4f}s {calls} calls  {stat.usec_per_call:8.1f} us/call{marker}")

It is deliberately defensive: a missing binary, a timeout, and an unparseable table each raise a typed StraceError rather than returning silently wrong data. The check=False is intentional — the program you are tracing is allowed to exit non-zero; that is frequently the entire reason you are tracing it.

strace vs ltrace vs gdb vs perf — pick the right lens

strace is one lens, not the only one. Each tool observes a different layer at a different cost, and reaching for the wrong one wastes time or perturbs the very behaviour you are chasing.

Tool	Observes	Overhead	Best question	Production-safe?
strace	Syscalls (kernel boundary)	High (2 ctx switches/call)	What is the process asking the kernel to do?	No — diagnosis only
ltrace	Library / function calls (userspace)	High	Which library calls fire, with what arguments?	No
gdb	Full program state, memory, breakpoints	Very high (stops the world)	What is the exact state at this line?	No (interactive)
perf trace	Syscalls via perf_events	Low	How do syscalls behave under real load?	Yes
bpftrace / eBPF	Arbitrary kernel + user probes	Very low	Custom, low-overhead production tracing	Yes

When not to reach for strace

The overhead is not academic, and it is not the only constraint. On hardened systems, /proc/sys/kernel/yama/ptrace_scope can forbid attaching to a process you do not own — you will get EPERM no matter how root you feel. Inside containers, a restrictive seccomp profile may block ptrace entirely. And on a service handling live traffic, doubling the cost of every syscall is not a debugging session, it is an incident.

For anything that must run against production load, reach for perf trace or an eBPF tool such as bpftrace, which observe the same syscall boundary at a fraction of the cost. But on a box you control, with a process you can afford to slow down, strace remains the fastest way to answer the only question that matters when intent and reality diverge: what is this process actually doing? Once you can read its output fluently, that question stops being a mystery and becomes a lookup.

Originally published on devmindset.dev — Linux internals, systems programming, and the self-taught developer mindset.

Related deep-dives:

DEV Community: Piotrek Karasinski

Signals in Linux — SIGKILL, SIGTERM, SIGCHLD and the Anatomy of a Handler

What a signal is — from the kernel's perspective

Signal dispositions: three possible reactions

SIGKILL and SIGSTOP — why you can't catch them

SIGCHLD and zombie processes

Async-signal-safety: what's allowed in a handler

SA_RESTART and interrupted syscalls

Diagnostics: inspecting signals in a running process

Summary

Building an MCP Server in Python — Architecture, FastMCP, and Production Code

What MCP actually solves

Three primitives: tools, resources, and prompts

Transport: stdio vs Streamable HTTP

A minimal production MCP server — FastMCP

Error handling that helps the model

Security: why tool descriptions are untrusted

State, concurrency, and scaling

Conclusion

malloc internals — Why free() Doesn't Return Memory to the System

Why Your Process's RSS Grows and Doesn't Shrink

The Intermediate Layer: Why We Don't Call the Kernel Directly

Anatomy of a Chunk — How malloc Remembers Sizes

Bins — The Structure for Managing Free Chunks

Why free() Doesn't Return Memory

mmap vs brk — Why Large Allocations Are Different

Arenas — Multithreaded Scaling

Alternative Allocators — Measurement, Not Ideology

Diagnostics — Tools

Conclusion: The Allocator as a Layer You Must Understand

Related articles

cgroups v2 as a Native Runtime Isolation Primitive — No Docker Required

The Overhead Tax of Container Abstraction

cgroups v2: Architectural Shift from v1

Unified Hierarchy Verification

Direct Cgroup Lifecycle Management

Creating and Configuring a Cgroup

Systemd Integration: Transient Units as Isolation Primitive

Programmatic Control via Python

Overhead Comparison: Docker vs. Direct cgroups v2

Conclusion: Choosing the Right Isolation Primitive

strace as a Debugging Primitive — When the Stack Trace Lies

What strace actually observes

Reading a trace line — the part nobody teaches

The flags that separate signal from noise

From raw trace to an actionable summary

strace vs ltrace vs gdb vs perf — pick the right lens

When not to reach for strace