Re: [RFC PATCH 0/1] close(): stop exposing non-retryable EINTR

[Alejandro Colomar]

Hi Mikko,

> Date: 2026-09-14 09:36:58+0300
> From: Mikko Rantalainen <mikko.rantalainen@xxxxxxxx>
>
> Rich Felker (2026-09-13 23:53 Europe/Helsinki):
> > On Sun, Sep 13, 2026 at 10:38:14PM +0300, Mikko Rantalainen wrote:
> >> In addition, POSIX.1-2024 requires that if close() reports EINTR, the
> >> descriptor must remain open. It also explicitly permits an interrupted
> >> close() to return success after closing the descriptor.
> >>
> >> This patch is about implementing the second option to be compatible with
> >> both POSIX.1-2024 and real-world applications.
> > ...
> > 
> > I don't think there is serious concern about userspace regressions
> > making this change. It would not be changing the meaning of any
> > existing result code or adding a new error condition applications need
> > to be aware of (like the EINPROGRESS mess).
> > 
> > But I'm also not sure how helpful the change would be. It's already
> > possible to patch this up in userspace, and as you noted, we already
> > do that in musl and so does Bionic. So the main practical effect of
> > this change would be just forcing the right behavior on glibc systems
> > even when glibc doesn't want to fix it. Maybe that's a good idea? I'm
> > not sure. I think it would be best to have everyone on the same page
> > that this should be fixed, with both glibc fixing it so it's right on
> > old-kernel/new-glibc, and the kernel fixing it so it's right on
> > new-kernel/old-glibc. That would also avoid hard feelings from a
> > unilateral action perceived as dictatorial.
> 
> I think there are two important questions:
> 
> 
> (1) What is the caller truly expected to do for EINTR? They cannot
> retry which would be the typical response to EINTR.
> 
> (2) If caller cannot retry because file was already closed, can caller
> have any valuable information from EINTR return instead of success?
> I think it's pretty safe assumption that success from close() would
> be handled correctly by the caller.

There's one thing a caller might do:

Let's say I have a program doing a backup, and close(2) reports EINTR.
I might decide that I don't trust any of what happened, and start the
backup again from scratch.

Of course, I should have sync(2)ed before calling close(2).  So this
should be a non-issue in the first place.

This is the one thing that makes me think it might be better to keep
close(2) broken: it would be a reminder that people should flush
everything before calling close(2) if they care about their files.


Have a lovely day!
Alex

> 
> 
> I'm currently thinking that the answer to (1) is "???" and answer to
> (2) is best you can do is to log "Some unknown action interrupted
> some unknown background process while closing file XYZ, pretending
> everything went well." because anything else would assume some
> specific implementation of close() on Linux.
> 
> As I see it, the fact that avoiding EINTR return value when the file
> is already closed fixing POSIX.1-2024 compatibility and glibc is just
> a bonus for a change that makes sense otherwise, too.
> 
> -- 
> Mikko
> 

-- 
<https://www.alejandro-colomar.es>

Attachment: signature.asc
Description: PGP signature