From: "Theo de Raadt" Subject: Re: FD state after close(2) error? To: Martijn Dekker Cc: Tech-OpenBSD Date: Fri, 07 Aug 2026 09:39:34 -0600 Martijn Dekker wrote: > Is there any scenario where a file descriptor passed to close(2) > remains, or might remain, open if EINTR or EIO occurs? The manual page > does not document this. It does document it, in the first sentence: DESCRIPTION The close() call deletes a descriptor d from the per-process object reference table. Nothing later on disagrees with this sentence. In the kernel, this is sys_close -> fdrelease -> fdremove, and nothing stops the fd from being removed from the process. The desciptor is removed first, then other stuff happens. From fdremove -> fclosef. That could, in obscure cases return additional errors from a lower-level (perhaps a filesystem), but such circumstance do not contradict the firm sentence at the start of the manual page. The descriptor was deleted before a condition occurs. The addition of error return values to close() by POSIX has been contentious since the start, because it makes this system call operation non-ACID (even when returning an error, it has performed a step). This mainly arrived because of a weird behaviour in NFS. But many believe the specification was a mistake, because no program is prepared or capable of taking corrective action when these errors occur, because sufficient information about the issue isn't reported AND because the descriptor which would be needed for resolution has been deleted (see the first sentence).