Re: [PATCH] retry opening startup files on EINTR

[Grisha Levit]

On Mon, Feb 19, 2024 at 5:10 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 2/7/24 1:33 AM, Grisha Levit wrote:
> > I have some dotfiles symlinked to storage backed by a macOS File
> > Provider extension (e.g. Dropbox):
> >
> >      $ realpath ~/.bash_profile
> >      /Users/levit/Library/CloudStorage/Dropbox/profile/.bash_profile
> >
> > This normally works fine, except when my terminal emulator (tested
> > both Terminal.app and iTerm) restores sessions after being restarted
> > -- opening the startup file fails in about half of the restored
> > sessions, which ends up looking like:
> >
> >      [Restored Feb 7, 2024 at 00:11:37]
> >      Last login: Wed Feb  7 00:11:37 on ttys008
> >      Restored session: Wed Feb  7 00:11:27 EST 2024
> >      -bash: /Users/levit/.bash_profile: Interrupted system call
> >      mbp:~ levit$
> >
> > If I remove ~/.bash_profile, and make ~/.inputrc and ~/.bash_history
> > similar symlinks, I see the same issue with loading them (without an
> > error message).
> >
> > I'm not sure what the underlying cause is here, but maybe it would be
> > appropriate to retry open(2) calls for these files if they fail with
> > EINTR?
>
> What's the underlying signal here? I hope it's not SIGINT.

Looks like it's a SIGWINCH getting sent -- so the Dropbox thing is only
relevant in that it makes the open(2) take a while.

Reproducible more easily on Linux with:

    strace -e openat -e inject=openat:signal=SIGWINCH:error=EINTR:when=1 \
        -P ~/.bashrc ./bash -i <&-

Though a similar test shows that the Readline part of the patch is wrong,
and I'm not sure how to solve it, at least without changing existing
applications' behavior (and requiring signal setup to happen before
rl_initialize or rl_read_init_file are called).