On Thu, Jul 02, 2020 at 09:07:46AM +0200, R. Diez wrote:
> I managed to make it fail once with:
>
> strace -f -- git fsck --progress
>
> The signal involved is SIGALRM. I am guessing that Git is setting it up in
> order to display its progress messages. This is one of the few calls to
> rt_sigaction(SIGALRM):
>
> rt_sigaction(SIGALRM, {sa_handler=0x556c8ac0fe80, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbdca7da890}, NULL, 8) = 0
That makes sense (and likewise your "--quiet" workaround seems
reasonable).
> I am not an expert in Unix signals, but I'll do my best here.
>
> I do not understand why Git is getting these interruptions due to SIGALRM, because SA_RESTART is in place.
>
> Interestingly, the man page signal(7) does list open() under that flag, but not openat().
Yes, though since open(2) says:
The openat() system call operates in exactly the same way as open(),
except for the differences described here.
I'd expect that would include any SA_RESTART handling. Peeking at the
Linux implementation in fs/open.c, it looks like both syscalls quickly
end up in the same do_sys_open().
> The description for open() under SA_RESTART is also interesting:
>
> * open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).
>
> I am not sure that opening a normal disk file may qualify as "can block" with that definition though.
Delivering EINTR on a non-blocking call seems even more confusing,
though. I think the "if it can block" is just "you won't even get a
signal if it's not blocking".
This really _seems_ like a kernel bug, either:
- openat() does not get the same SA_RESTART treatment as open(); or
- open() on a network file can get EINTR even with SA_RESTART
But it's quite possible that I'm missing some corner case or historical
reason that it would need to behave the way you're seeing. It might be
worth reporting to kernel folks.
-Peff
