Re: [RFC v1] man/man2/close.2: CAVEATS: Document divergence from POSIX.1-2024

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

> On Tue, Jan 20, 2026 at 12:05:52PM -0500, Zack Weinberg wrote:
>> > On Fri, May 23, 2025 at 02:10:57PM -0400, Zack Weinberg wrote:
>> >>     close() always succeeds.  That is, after it returns, _fd_ has
>> >>     always been disconnected from the open file it formerly referred
>> >>     to, and its number can be recycled to refer to some other file.
>> >>     Furthermore, if _fd_ was the last reference to the underlying
>> >>     open file description, the resources associated with the open file
>> >>     description will always have been scheduled to be released.
>> ...
>> >>     EINPROGRESS
>> >>     EINTR
>> >>            There are no delayed errors to report, but the kernel is
>> >>            still doing some clean-up work in the background.  This
>> >>            situation should be treated the same as if close() had
>> >>            returned zero.  Do not retry the close(), and do not report
>> >>            an error to the user.
>> >
>> > Since this behavior for EINTR is non-conforming (and even prior to the
>> > POSIX 2024 update, it was contrary to the general semantics for EINTR,
>> > that no non-ignoreable side-effects have taken place), it should be
>> > noted that it's Linux/glibc-specific.
>> 
>> I am prepared to take your word for it that POSIX says this is
>> non-conforming, but in that case, POSIX is wrong, and I will not be
>> convinced otherwise by any argument.  Operations that release a
>> resource must always succeed.
>
> There are two conflicting requirements here:
>
> 1. Operations that release a resource must always succeed.
> 2. Failure with EINTR must not not have side effects.
>
> The right conclusion is that operations that release resources must
> not be able to fail with EINTR. And that's how POSIX should have
> resolved the situation -- by getting rid of support for the silly
> legacy synchronous-tape-drive-rewinding behavior of close on some
> systems, and requiring close to succeed immediately with no waiting
> for anything.

What about SO_LINGER?  Isn't this relevant in context?

As far as I know, there is no other way besides SO_LINGER to get
notification if the packet buffers are actually gone.  If you don't use
it, memory can pile up in the kernel without the application's
knowledge.

Thanks,
Florian