Re: data loss when doing ls-remote and piped to command

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sep 17, 2021, 19:28 UTC
Message-ID: <CAHk-=wgv42Wm3uHPntZNEYFu-dDVYW7yRen1fUBi6keZaKb+_g@mail.gmail.com>
In-Reply-To: <2722184.bRktqFsmb4@devpool47>

On Thu, Sep 16, 2021 at 11:59 PM Rolf Eike Beer <eb@emlix.com> wrote:

Show 6 quoted lines

>
> When I run the whole thing with strace I can't see the effect, which isn't
> really surprising. But there is a difference between the cases where I run
> with redirection "2>&1":
>
> ioctl(2, TCGETS, 0x7ffd6f119b10)        = -1 ENOTTY (Inappropriate ioctl for device)

Ehh. That format of strace implies that you didn't use "strace -f" (which would have the PID in it).

Although maybe you edited it out.

I think the error output would come from the other process (ssh, or whatever process you use to run "git-upload-pack" on the other end).

I still strongly doubt it's about pipes - we've had changes to them, but if they are broken we'd see a lot more breakage than some very incidental use by git.

But I can easily see it being timing-dependent. And yes, sadly 'strace' can often end up hiding any timing issues because it obviously slows down the target quite a bit.

Doing "strace -o tracefile -f" in a loop would be interesting if you can reproduce it (and then stop when you reproduce it, so that the final 'tracefile' is the one for the case that reproduced it).

            Linus