On Fri, May 16, 2025 at 12:48:56PM +0200, Jan Kara wrote: > Hi! > > On Thu 15-05-25 23:33:22, Alejandro Colomar wrote: > > I'm updating the manual pages for POSIX.1-2024, and have some doubts > > about close(2). The manual page for close(2) says (conforming to > > POSIX.1-2008): > > > > The EINTR error is a somewhat special case. Regarding the EINTR > > error, POSIX.1‐2008 says: > > > > 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 fildes is unspecified. > > > > This permits the behavior that occurs on Linux and many other > > implementations, where, as with other errors that may be re‐ > > ported 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 de‐ > > scriptor 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 di‐ > > vergence 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. There are plans to ad‐ > > dress this conundrum for the next major release of the POSIX.1 > > standard. > > > > TL;DR: close(2) with EINTR is allowed to either leave the fd open or > > closed, and Linux leaves it closed, while others (HP-UX only?) leaves it > > open. > > > > Now, POSIX.1-2024 says: > > > > If close() is interrupted by a signal that is to be caught, then > > it is unspecified whether it returns -1 with errno set to > > [EINTR] and fildes remaining open, or returns -1 with errno set > > to [EINPROGRESS] and fildes being closed, or returns 0 to > > indicate successful completion; [...] > > > > <https://pubs.opengroup.org/onlinepubs/9799919799/functions/close.html> > > > > Which seems to bless HP-UX and screw all the others, requiring them to > > report EINPROGRESS. > > > > Was there any discussion about what to do in the Linux kernel? > > I'm not aware of any discussions but indeed we are returning EINTR while > closing the fd. Frankly, changing the error code we return in that case is > really asking for userspace regressions so I'm of the opinion we just > ignore the standard as in my opinion it goes against a long established > reality. I wonder what are they thinking there. Any program which even bothers to check for EINTR assumes the fd is already closed, so one has to assume augmenting behavior to support this would result in fd leaks. But that crappery aside, I do wonder if a close() variant which can fail and leaves the fd intact would be warranted. For example one of the error modes is ENOSPC (or at least the manpage claims as much). As is the error is not actionable as the fd is gone. If instead a magic flag was passed down to indicate what to do (e.g., leave the fd in place), the program could try to do some recovery (for examples unlinking temp files it knows it stores there). Similar deal with EINTR, albeit this error for close() would preferably get eradicated instead. Just some meh rambling.
