Git Mailing List Archive on
 help / color / Atom feed
From: Jeff King <>
To: "R. Diez" <>
Subject: Re: Interrupted system call
Date: Wed, 1 Jul 2020 12:21:11 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jul 01, 2020 at 11:43:15AM +0200, R. Diez wrote:

> After a 3-month pause, I recently updated my Ubuntu 18.04.4. I am
> using a PPA to keep Git more up to date, so I have now "git version
> 2.27.0".
> I am now getting this kind of errors:
> fatal: failed to read object cf965547a433493caa80e84d7a2b78b32a26ee35: Interrupted system call
> error: unable to mmap /home/rdiez/[blah blah]/SrcRepo.git/objects/2e/f96ffba4c0d60f36c8779758f82752be380689: Interrupted system call
> I am using a mount point for a network share. Keep in mind that Git thinks
> it is working on a local directory, so there should be no sockets or
> non-blocking I/O involved.

Looking at the code, that message is slightly deceptive. It's reporting
a failure from map_loose_object_1(), which calls both open() and mmap(),
as well as fstat().  It would be interesting to know which syscall is
actually failing. Running the failure case under "strace" would be
interesting (likewise to see which signal is causing the interruption).

> The problem is probably caused by using SMB to connect to an outdated
> Windows server. It has been working for years, but at some point in time it
> is bound to fail. The Linux kernel itself seems to introduce bugs in the
> SMB/CIFS code every now and then.
> Nevertheless, I am surprised to get such an "Interrupted system call" from
> Git. A long time ago I learnt that it is OK for many syscalls to get
> interrupted, so you have to loop around them. See here for more information:

We do check for signals and re-start read() and write() calls as
appropriate. We don't for open(), and nobody has ever complained (though
it definitely is documented to result in EINTR, I'd imagine it's
relatively rare). I'm not excited about the prospect of adding retry
code to every open(), though perhaps doing it with our git_open()
wrapper would be sufficient (it's unclear how stdio fopen() behaves).

> How can I pin-point this problem? I would like to know where Git is
> encountering this error, so that I can troubleshoot it, and maybe report yet
> another bug to the Linux SMB/CIFS maintainer.

I think the first step is using strace to record the system call
returning EINTR (and the signal that interrupted it). I suspect it's in
open(), though, and probably not a bug: opening network files may take a
while and need to be interruptable.


  parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-07-01  9:43 ` R. Diez
2020-07-01 14:22   ` Santiago Torres Arias
2020-07-01 16:21   ` Jeff King [this message]
2020-07-02  7:07     ` R. Diez
2020-07-15  9:38       ` Jeff King
2020-07-15 16:06         ` Chris Torek
2020-07-12  8:41     ` R. Diez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone