Linux

Linux / 16 Sep 2026 / 5 min read

Linux TCP TIME_WAIT Retains Closed Connection State

A TCP socket can disappear from an application while the kernel still retains state for the closed connection. On Linux, the endpoint that completes the active close commonly enters TIME_WAIT, keeping enough protocol state to protect a later connection from delayed segments associated with the old one. This state is not evidence that a process forgot to close a file descriptor. The application-visible socket can already be gone. TIME_WAIT belongs to TCP’s connection-lifecycle machinery and persists independently of the process that initiated the close.

Linux TCP

Linux / 16 Sep 2026 / 4 min read

Linux TCP Autocorking Coalesces Consecutive Small Writes

A small TCP write does not always trigger an immediate packet transmission on Linux. With TCP autocorking enabled, the stack can defer a new small send when an earlier packet from the same flow is still waiting in a qdisc or device transmit queue, giving a following write a chance to join the pending data. The mechanism targets packet count rather than application-visible buffering semantics. A successful write() or sendmsg() still reports bytes accepted by the socket; autocorking influences when queued bytes advance into transmission.

Linux TCP

Linux / 16 Sep 2026 / 6 min read

Linux Readahead Expands Sequential Page-Cache Reads

A buffered file read can cause Linux to fetch more data than the application explicitly requested. The extra I/O is readahead: the kernel populates nearby page-cache folios in anticipation of continued access. This behavior sits between application read size and storage request size. A process may issue modest read() calls while the kernel submits larger reads to keep later accesses from waiting on storage. Readahead is page-cache speculation Buffered file I/O normally passes through the page cache. When requested file data is absent, the kernel must arrange I/O for that miss. The readahead path can extend that operation across additional folios that are not yet present in the cache.

Linux Memory

Linux / 16 Sep 2026 / 5 min read

Linux PSI Separates Partial and Total Resource Stalls

A Linux host can report modest CPU utilization while runnable work is delayed, or ample memory capacity while tasks repeatedly stall in reclaim. Utilization counters describe resource activity; pressure stall information records time in which work cannot make progress because a resource is contended. PSI exposes that lost execution opportunity through CPU, memory, and I/O pressure files. Its central distinction is between a stall affecting at least one task and a stall that leaves every non-idle task unable to make progress.

Linux PSI

Linux / 16 Sep 2026 / 6 min read

Linux cgroup memory.high Converts Overage into Reclaim Pressure

A cgroup can remain alive after its memory usage crosses memory.high. The boundary does not behave like a hard allocation ceiling: tasks in the cgroup are throttled and pushed into heavy reclaim pressure, and usage can remain above the configured value under extreme conditions. That behavior makes memory.high materially different from memory.max. The former converts excess usage into execution cost and reclaim work. The latter is a hard limit that can lead to a cgroup OOM when reclaim cannot reduce usage enough.

Linux cgroup v2

Linux / 16 Sep 2026 / 5 min read

io_uring Registered Files Bypass Repeated Descriptor Lookup

An io_uring request that uses a normal file descriptor still has to resolve that descriptor through the submitting task’s file table. A registered file takes a different path: the ring holds a reference to the open file, and an SQE names a slot in that ring-local table. That distinction removes repeated descriptor lookup from the request path. It also changes resource lifetime, update semantics, and the meaning of the SQE fd field.

Linux io_uring

Tech / 15 Sep 2026 / 7 min read

ARP Neighbor Cache Reuses Local IP-to-MAC Mappings

Sending an IPv4 packet across an Ethernet network requires two different kinds of addresses. The IP layer selects a next-hop IPv4 address, while the Ethernet frame needs a destination MAC address that identifies the next hop on the local link. Address Resolution Protocol (ARP) connects those two layers. A host can ask which MAC address corresponds to a local IPv4 address, receive a reply, and store the resulting mapping. Keeping that result in a neighbor cache avoids broadcasting the same question before every packet.

Networking ARP

Linux / 07 Sep 2026 / 12 min read

Understand Sparse Files on Linux Without Wasting Disk Space

A file can report a size of 100 GiB without consuming 100 GiB of disk blocks. That sounds contradictory until you separate two ideas that ordinary file APIs often present together: a file’s logical size and the storage that the filesystem has actually allocated for it. Linux filesystems can represent long ranges of unwritten bytes as holes. Reading a hole returns zero bytes, but the filesystem does not need to store one physical zero byte for every logical byte in that range. A regular file that contains holes is called a sparse file.

Linux File Systems

Linux / 06 Sep 2026 / 13 min read

Choose the Right Advisory File Lock on Linux

Two processes can open the same file and both write to it successfully. That is often exactly what Unix applications need, but sometimes the programs are supposed to coordinate: only one worker should update a state file, several readers may share a resource, or a process must avoid changing a byte range while another process is using it. Linux offers several advisory file-locking mechanisms. The confusing part is not how to request a lock. The confusing part is what owns the lock and when that lock disappears.

Linux System Calls

Linux / 05 Sep 2026 / 11 min read

Wake Linux Event Loops from Other Threads with eventfd

A file-descriptor event loop can wait efficiently for sockets, pipes, timers, and other kernel objects. A common problem appears when work originates somewhere that is not already represented by a file descriptor: another thread changes shared state and needs the loop to wake immediately. Polling shared state on a timer adds latency or wastes wakeups. A condition variable can wake a thread, but it cannot be placed directly in the same poll() or epoll wait set as a socket. A pipe can bridge the two models, but using a pipe only as a wakeup signal means maintaining a read end, a write end, and byte-buffer semantics that the application may not actually need.

Linux Concurrency

Linux / 05 Sep 2026 / 12 min read

Pass Open File Descriptors Between Linux Processes with SCM_RIGHTS

Processes often need to hand each other access to an already-open resource. A supervisor may accept a client connection and delegate it to a worker. A privileged helper may open a protected file, then give an unprivileged process access without revealing broader filesystem permissions. A service may create an anonymous in-memory file and transfer it to another process. Sending the integer value of a file descriptor does not solve this problem. File descriptor numbers are meaningful only inside one process’s descriptor table. Descriptor 7 in one process can refer to a socket while descriptor 7 in another process refers to an unrelated file.

Linux IPC

Linux / 05 Sep 2026 / 10 min read

Move Data Between Linux File Descriptors with splice()

A conventional file-copy loop reads bytes into a user-space buffer and then writes those bytes somewhere else. That pattern is portable and easy to understand, but sometimes the program does not need to inspect or transform the data at all. It only needs to move bytes from one file descriptor to another. On Linux, splice() can handle that case differently. It transfers data between file descriptors while keeping the transferred data out of a user-space buffer. At least one endpoint must be a pipe, so a pipe can act as the kernel-side bridge between a source and a destination.

Linux System Calls

Linux / 05 Sep 2026 / 9 min read

Create Sealable In-Memory Files on Linux with memfd_create

Applications often need a temporary chunk of data that behaves like a file without needing a persistent pathname. A process may build a configuration snapshot, compiled artifact, or serialized message, then map it into memory or pass it to another process. A regular temporary file can do that, but it introduces filesystem naming, cleanup, permissions, and lifetime concerns. An anonymous mmap() avoids the pathname, but it does not produce an ordinary file descriptor that can be passed to APIs expecting file-backed data.

Linux System Calls

Linux / 04 Sep 2026 / 8 min read

Write Files Atomically on Linux with rename and fsync

Updating a small file looks simple: open it, truncate it, write the new contents, and close it. That works when nothing interrupts the write. The failure mode appears when a process crashes, the machine loses power, or another process reads the file while it is being rewritten. A reader can observe an empty or partially written file, and a crash can leave the pathname referring to incomplete data. For configuration files, state snapshots, generated metadata, and similar single-file updates, a better pattern is to write a complete replacement beside the original file and then rename it into place.

Linux Filesystems

Linux / 04 Sep 2026 / 13 min read

Understand Memory-Mapped Files on Linux with mmap

Reading a file usually means calling read() and copying bytes into a buffer that your program manages. That model is explicit and works well for most file I/O. Linux offers another model with mmap(): map a file region into the process’s virtual address space, then access the file through ordinary memory loads and stores. That can simplify workloads such as random access into large files, shared file-backed state, indexes, and binary formats whose access pattern naturally looks like “read bytes at offset N.” It can also avoid an application-managed read buffer for those accesses.

Linux Memory Management

Linux / 04 Sep 2026 / 12 min read

Understand Linux File Descriptor Duplication and Shell Redirection

Shell redirection looks compact: command >output.log 2>&1 But that syntax hides a useful systems concept. The shell is not asking the command to “log somewhere else.” It is changing the command’s file descriptors before the program starts.

Linux File I/O

Linux / 04 Sep 2026 / 13 min read

Prevent Overlapping Linux Jobs with Advisory File Locks and flock

A scheduled job often looks harmless until two copies run at the same time. A backup takes longer than usual, a second timer fires, and both processes start writing the same output. A maintenance script overlaps with itself and launches duplicate work. A cache refresh runs concurrently and leaves partially coordinated state behind. The problem is not that Linux started the processes incorrectly. The problem is that the application needs a rule saying, “only one cooperating process may enter this critical section at a time.”

Linux Concurrency

Linux / 04 Sep 2026 / 11 min read

Integrate Timers into Linux Event Loops with timerfd

Event loops work best when unrelated kinds of work have one common waiting mechanism. Sockets become readable. Pipes become writable. A child-process descriptor or signal descriptor can become ready. Timers are often the awkward exception. A program can call sleep() or nanosleep(), but that blocks the thread instead of letting it wait for I/O. It can pass a timeout to poll() or epoll_wait(), but one timeout becomes difficult to manage when the program has several independent deadlines. Traditional POSIX timers can deliver signals, which introduces a second asynchronous control path.

Linux Timers

Linux / 04 Sep 2026 / 9 min read

Handle Linux Signals in Event Loops with signalfd

Unix signals are asynchronous by design: a signal can interrupt a program between ordinary instructions and transfer control to a signal handler. That model is useful, but it creates an awkward boundary for event-driven programs. A network server may already spend most of its time inside poll(), epoll_wait(), or another readiness API. Its sockets, pipes, and timers appear as file-descriptor events, while SIGTERM and SIGHUP arrive through a separate execution path with much stricter rules about what code may safely run.

Linux Signals

Linux / 04 Sep 2026 / 8 min read

Avoid PID Reuse Races on Linux with pidfds

A process ID looks like an identity, but it is really a reusable number. That distinction matters in long-running supervisors, job managers, test harnesses, and other programs that observe a process and then act on it later. Between those two operations, the original process can exit and Linux can eventually reuse the same PID for an unrelated process. Traditional PID-based code can therefore have a time-of-check/time-of-use race: check PID 4242 -> original process exits -> PID 4242 is reused -> signal PID 4242 Linux PID file descriptors, usually called pidfds, provide another model. Instead of repeatedly identifying a task by a reusable integer, a program obtains a file descriptor that refers to a particular process and can use that descriptor with pidfd-aware APIs.

Linux Processes

Linux / 02 Sep 2026 / 5 min read

Inspect Process Isolation with Linux Namespaces

Containers rely on several Linux kernel features, but namespaces provide much of the process-level isolation people notice first. They let different groups of processes see different views of resources such as process IDs, mounts, hostnames, and network interfaces. You do not need a container runtime to inspect namespaces. Standard Linux tools and /proc expose the relationships directly. What a namespace changes A namespace virtualizes one class of global system resource.

Linux Namespaces

Linux / 02 Sep 2026 / 4 min read

Diagnosing File Descriptor Leaks on Linux with procfs

A Linux process uses file descriptors for more than ordinary files. Network sockets, pipes, event descriptors, terminals, and many other kernel objects appear through the same integer-based interface. When a service slowly accumulates descriptors, it may eventually fail with Too many open files, stop accepting connections, or behave unpredictably under load. Linux procfs provides enough information to investigate many descriptor leaks without installing extra tools. Start by counting descriptors For a known process ID:

Linux procfs

Linux / 01 Sep 2026 / 6 min read

Troubleshooting systemd Services with systemctl and journalctl

When a Linux service fails under systemd, the fastest path to a fix is usually not restarting it repeatedly. A better approach is to inspect the service state, read the relevant logs, confirm the effective unit configuration, and validate changes before trying again. This guide presents a repeatable troubleshooting workflow for modern Linux distributions that use systemd. The examples use commands available in systemd 257, but the core workflow also applies to many earlier systemd releases.

Linux systemd

Linux / 01 Sep 2026 / 2 min read

Troubleshoot Linux Services with systemd and journalctl

On systemd-based Linux distributions, a service that “will not start” can fail for many reasons: an invalid command, missing file, permission problem, dependency failure, timeout, or application crash. A repeatable workflow is faster than repeatedly restarting the unit. Start with unit state systemctl status example.service Look at Loaded, Active, the main process exit status, and the most recent log lines. A unit can be loaded correctly while its process exits immediately.

Linux systemd