Tracking File Descriptor Leaks

Identify processes that fail to close resources by auditing their file descriptor tables.

In this lesson, you will learn how to identify "leaky" processes that fail to close their file descriptors, potentially leading to system-wide resource exhaustion.

What is a File Descriptor Leak?

Every time a process opens a file, socket, or pipe, the Linux kernel assigns it a unique integer called a File Descriptor (FD). There is a hard limit on how many FDs a single process can hold open at once. If a program repeatedly opens resources but fails to close() them—often due to poor error handling or logic bugs—it eventually hits this limit, causing the application to crash or behave unpredictably.

Auditing the FD Table

Because procfs acts as our "process information engine," we don't need fancy debugging tools to inspect these leaks. Every process keeps its currently open file descriptors in the /proc/[PID]/fd/ directory.

You can inspect the FDs of a suspicious process by listing the contents of that directory:

# List all file descriptors held by PID 1234
ls -l /proc/1234/fd

This command will output a list of symbolic links. Each link represents an open resource. If you see thousands of entries pointing to the same socket or file, you have confirmed a leak.

Identifying the Pattern

When auditing, look for:

Redundancy: Hundreds of links pointing to the exact same log file or database socket.
"Anonymous" pipes: Numerous entries labeled pipe:[...] which often signify threads that are spawning sub-processes without closing communication channels.
Ghost connections: Sockets in a CLOSE_WAIT state that refuse to disappear, suggesting the application logic isn't cleaning up its network handles.

By checking the count of files in /proc/[PID]/fd/ over time, you can verify if the number is growing monotonically. If it never shrinks, the process is leaking handles. You can check the current count quickly with:

ls /proc/1234/fd | wc -l

If this number keeps climbing while the program performs the same task, you have identified a classic resource leak that needs developer attention.

Key Takeaway: A file descriptor leak is identified by monitoring the /proc/[PID]/fd/ directory and detecting a constantly growing count of open handles that fail to close over time.