CLOSE(2)

✨ CLOSE(2) ✨

okay bestie, we're in the System Calls Manual and this one is lowkey the most underrated baddie in the whole syscall roster 💅 it's close from the Standard C Library (libc, -lc) and yes, it's exactly what it sounds like.

---

🌸 NAME 🌸

close — delete a descriptor 🗑️✨

---

🎀 LIBRARY 🎀

Standard C Library (libc, -lc)

---

🦋 SYNOPSIS 🦋

#include <unistd.h>

int
close(int fd);

---

💖 DESCRIPTION 💖

so the close() system call deletes a descriptor from the per-process object reference table. that's the whole vibe. and if that was the last reference to the underlying object? the object gets deactivated. gone. bye. 😭

like, for example:

• on the last close of a file, the current seek pointer associated with the file is lost
• on the last close of a socket(2), associated naming information and queued data are discarded
• on the last close of a file holding an advisory lock, the lock is released (see further flock(2))

but hold on, plot twist 🫢 — the semantics of System V and IEEE Std 1003.1-1988 (“POSIX.1”) dictate that all fcntl(2) advisory record locks associated with a file for a given process are removed when any file descriptor for that file is closed by that process. not just the last one. any. periodt.

---

when a process exits, all associated file descriptors are freed, no cap. but since there's a limit on active descriptors per process, the close() system call is genuinely useful when a large quantity of file descriptors are being handled. resource management queen 👑

---

when a process forks (see fork(2)), all descriptors for the new child process reference the same objects as they did in the parent before the fork. sibling energy fr fr 👯

if a new process is then to be run using execve(2), the process would normally inherit these descriptors. most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve(2) is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds.

for this reason, the call:

fcntl(d, F_SETFD, FD_CLOEXEC)

is provided, which arranges that a descriptor will be closed after a successful execve. and the call:

fcntl(d, F_SETFD, 0)

restores the default, which is to not close the descriptor. iconic little toggle tbh ⭐

---

💜 RETURN VALUES 💜

the close() function returns the value 0 if successful 🎉 otherwise the value -1 is returned and the global variable errno is set to indicate the error. classic.

---

🔥 ERRORS 🔥

the close() system call will fail if:

• [EBADF] — the fd argument is not an active descriptor.
• [EINTR] — an interrupt was received.
• [ENOSPC] — the underlying object did not fit, cached data was lost.
• [ECONNRESET] — the underlying object was a stream socket that was shut down by the peer before all pending data was delivered.

⚠️ IMPORTANT BESTIE: in case of any error except EBADF, the supplied file descriptor is deallocated and therefore is no longer valid. do not go touching it afterwards, she's gone 🙈

---

🌈 SEE ALSO 🌈

accept(2), closefrom(2), execve(2), fcntl(2), flock(2), open(2), pipe(2), socket(2), socketpair(2)

---

👑 STANDARDS 👑

the close() system call is expected to conform to ISO/IEC 9945-1:1990 (“POSIX.1”). slay.

---

⭐ HISTORY ⭐

the close() function appeared in Version 1 AT&T UNIX. an absolute OG, we stan a legend 🫶

---

and that's the whole page bestie 💖 this came to you from Debian, dated December 1, 2017 — go forth and close your descriptors responsibly, mwah 🎀✨