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 07:39:48PM +0100, Florian Weimer wrote:
>> * 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?
>
> shutdown should be used for this, not close. So that the acts of
> waiting for the operation to finish, and releasing the resource handle
> needed to observe if it's finished, are separate.

I think shutdown on TCP sockets is non-blocking under Linux.  It doesn't
wait until the peer has acknowledged the FIN segment, as far as I
understand it.  Other systems may behave differently.

>> 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.
>
> The way Linux's EINTR behaves, using close can't ensure this memory
> doesn't pile up, because on EINTR you lose the ability to wait for it.

Can't the application reliably avoid EINTR by blocking signals?

Thanks,
Florian