On Wed, Dec 04, 2024 at 08:59:03PM -0700, Dmitriy Panteleyev wrote:
> Strace with NO_MMAP=1, I gives:
>
> openat(AT_FDCWD,
> ".git/objects/34/5819b235838e219d66420b536a54ce4cf0624c",
> O_RDONLY|O_CLOEXEC) = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=154, ...}) = 0
> pread64(4, 0x61a0292e15d0, 154, 0) = -1 ESTALE (Stale file handle)
> write(2, "fatal: mmap failed: Permission d"..., 38) = 38
>
> Weirdly, it's throwing ESTALE not EACCESS...
Ah, interesting. So yeah, it seems like there is some configuration
issue or other problem that is causing your NFS handles to time out, and
we get unexpected failures while reading. I _think_ that exonerates the
commit you found, as the code it removed was helping only by chance, by
creating slightly different filesystem access patterns.
> > Does your system have AppArmor enabled?
>
> Yes, but I don't see any profiles related to git. And I can't image
> AppArmor would be version-dependent.
I think this was probably a long shot anyway. In the link I found it was
"man", which sensibly would have AppArmor profiles that disallow network
access. But clearly "git" would not have the same ones, since we expect
it to hit the network (not "git commit", but it is all one binary, so
AppArmor doesn't distinguish).
> Hrm. I just spun up a couple of different VMs on my server with old
> and new NFS versions, and git works fine from those shares.
>
> I think we should put a pin in it, since I can't reproduce the problem
> outside of my specific server instance.
Yeah, that makes sense. You might find something interesting in the
server-side logs that explains the stale NFS handles.
Thanks for going through all the back-and-forth. :)
-Peff
