close(2)

💖 close(2) — bestie we're closing a file descriptor 💖

so like... this is the close(2) page from the Linux man-pages, section 2 (system calls, if you didn't know 🫶). it lives in the System Calls Manual. buckle up, it's giving "short function, absolutely unhinged caveats" energy 💅

---

✨ NAME ✨

close — close a file descriptor. that's it. that's the whole job. iconic behavior honestly 👑

📚 LIBRARY 📚

Standard C library (libc, -lc) — the classic. she's always been there for you 🎀

🌸 SYNOPSIS 🌸

#include <unistd.h>

int close(int fd);

🦋 DESCRIPTION 🦋

okay so close() closes a file descriptor, meaning it no longer refers to any file and it may be reused (key word: may, bestie, more on that chaos later 😭).

here's the tea: any record locks (peep fcntl(2)) that are held on the file it was associated with, and that are owned by the process, get removed — regardless of which file descriptor was actually used to grab that lock. the way this has unfortunate consequences... yeah. one should be extra careful when using advisory record locking. head to fcntl(2) for the full discussion of the risks and consequences, plus the (probably preferred) open file description locks ✨

now if fd is the last file descriptor referring to the underlying open file description (see open(2)), the resources tied to that open file description get freed. and if that file descriptor was the last reference to a file that's already been removed using unlink(2)? the file is deleted, periodt 💀

🎀 RETURN VALUE 🎀

• returns zero on success ✨
• on error, -1 is returned, and errno is set to tell you what went wrong 😭

💅 ERRORS 💅

• EBADF — fd isn't a valid open file descriptor. it's giving "who even are you" 🙈
• EINTR — the close() call was interrupted by a signal; see signal(7) 🛑
• EIO — an I/O error occurred. she's not well 💀
• ENOSPC
• EDQUOT — on NFS, these errors are not normally reported against the first write(2) which exceeds the available storage space, but instead against a subsequent write(2), fsync(2), or close(). sneaky behavior fr fr

also go read CAVEATS for the discussion of why close() should not be retried after an error. this is important, bestie, don't skip it 🚨

⭐ STANDARDS ⭐

POSIX.1-2008. certified, validated, standardized, slay ✨

🌈 HISTORY 🌈

4.3BSD, SVr4, POSIX.1-1988. she's been around since forever and she's still thriving 👑

💜 NOTES 💜

the close-on-exec file descriptor flag can be used to make sure a file descriptor is automatically closed upon a successful execve(2) — see fcntl(2) for the details. set it and forget it energy 🧚

🚨 CAVEATS 🚨

okay this is the main character section, pay attention 😤

a successful close does not guarantee that the data has been successfully saved to disk, because the kernel uses the buffer cache to defer writes. typically, filesystems do not flush buffers when a file is closed. so if you need to be sure the data is physically stored on the underlying disk, use fsync(2). (and even then, at that point it'll depend on the disk hardware, so 😭)

🧵 Multithreaded processes and close() 🧵

ngl it is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects. not the vibe. 🙈

furthermore, consider the following scenario where two threads are performing operations on the same file descriptor:

1. One thread is blocked in an I/O system call on the file descriptor. For example, it is trying to write(2) to a pipe that is already full, or trying to read(2) from a stream socket which currently has no available data. 💤
2. Another thread closes the file descriptor. 🚪💨

the behavior in this situation varies across systems. on some systems, when the file descriptor is closed, the blocking system call returns immediately with an error.

on Linux (and possibly some other systems), the behavior is different: the blocking I/O system call holds a reference to the underlying open file description, and this reference keeps the description open until the I/O system call completes. (see open(2) for a discussion of open file descriptions.) so the blocking system call in the first thread may successfully complete after the close() in the second thread. plot twist 🔥

😭 Dealing with error returns from close() 😭

a careful programmer will check the return value of close(), since it's quite possible that errors on a previous write(2) operation are reported only on the final close() that releases the open file description. failing to check the return value when closing a file may lead to silent loss of data. this can especially be observed with NFS and with disk quota. that's the scary part fr fr 💀

note, however, that a failure return should be used only for diagnostic purposes (i.e., a warning to the application that there may still be I/O pending or there may have been failed I/O) or remedial purposes (e.g., writing the file once more or creating a backup).

Retrying the close() after a failure return is the wrong thing to do, since this may cause a reused file descriptor from another thread to be closed. this can occur because the Linux kernel always releases the file descriptor early in the close operation, freeing it for reuse; the steps that may return an error, such as flushing data to the filesystem or device, occur only later in the close operation. so like... the fd is already gone, bestie, let her go 😭

many other implementations similarly always close the file descriptor (except in the case of EBADF, meaning that the file descriptor was invalid) even if they subsequently report an error on return from close(). POSIX.1-2008 was silent on this point. 🤐

a careful programmer who wants to know about I/O errors may precede close() with a call to fsync(2). do that. glow up your error handling ✨

the EINTR error is a somewhat special case. regarding the EINTR error, POSIX.1-2008 said:

If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to EINTR and the state of fd is unspecified.

this permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by close(), the file descriptor is guaranteed to be closed. however, it also permits another possibility: that the implementation returns an EINTR error and keeps the file descriptor open. (according to its documentation, HP-UX's close() does this.) the caller must then once more use close() to close the file descriptor, to avoid file descriptor leaks. this divergence in implementation behaviors provides a difficult hurdle for portable applications, since on many implementations close() must not be called again after an EINTR error, and on at least one, close() must be called again. absolutely cursed situation, no cap 😵

POSIX.1-2024 standardized the behavior of HP-UX, making Linux and many other implementations non-conforming. there are no plans to change the behavior on Linux. so... yeah. Linux said "we're staying like this" and honestly? respect 💅

👀 SEE ALSO 👀

close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3) — go read them, they're the extended universe 🦋

---

okay that's the whole page, bestie! this one came from Linux man-pages 6.20, dated 2026-02-08, and it's the close(2) page 💖 now go fsync() before you close, you absolute legend 🫶✨🎀