git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Possible race condition with git-rebase + .git/index.lock

From
SJSergio Durigan Junior <sergiodj@sergiodj.net>
Date
Mar 13, 2019, 20:48 UTC
Message-ID
<87pnqu4i1n.fsf@sergiodj.net>
In-Reply-To
<e0e1e159-844d-c9bf-e1cc-ada05384ef76@gmail.com>
On Wednesday, March 13 2019, Phillip Wood wrote:
Show 47 quoted lines
> Hi Sergio
>
> On 12/03/2019 19:32, Sergio Durigan Junior wrote:
>> On Tuesday, March 12 2019, Elijah Newren wrote:
>>
>>> On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
>>> <sergiodj@sergiodj.net> wrote:
>>>> On Tuesday, March 12 2019, Duy Nguyen wrote:
>>>>
>>>>> On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
>>>>> <sergiodj@sergiodj.net> wrote:
>>>>>> This works without problems most of the time (well, usually there are
>>>>>> conflicts and all, but that's a burden I have to carry).  However,
>>>>>> sometimes I notice that git fails with:
>>>>>>
>>>>>>    # git rebase origin/master
>>>>>>    ...
>>>>>>    Applying: commitX
>>>>>>    Applying: commitY
>>>>>>    Applying: commitZ
>>>>>>    fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.
>>>>>>
>>>>>> The first thing I did was to check whether the index.lock file existed,
>>>>>> but it doesn't.
>>>>>
>>>>> Is the output this clean? What I'm looking for is signs of automatic
>>>>> garbage collection kicking in the middle of the rebase. Something like
>>>>> "Auto packing the repository blah blah for optimum performance".
>>>>
>>>> Yeah, this is the exact output.  I also thought about "git gc", but I
>>>> don't see any output related to it.  Is it possible that it's being
>>>> executed in the background and not printing anything?
>>>
>>> Any chance you have a cronjob or other task execution mechanism that
>>> is running git commands in various directories (even simple commands
>>> like 'git status' since it's not read-only contrary to what some
>>> expect, or 'git fetch' which might trigger a background gc)?
>>
>> Nope, nothing like this.  AFAIK, nothing is touching that repository at
>> the same time that I am.  Besides, even if I wait some minutes before
>> trying again, the bug manifests again.
>>
>
> Do you have any of the files in the repository open in an editor or
> ide while you are rebasing? I have seen this message when rebasing and
> one of the files is open in emacs which runs git status when it sees a
> file has changed which locks the index while the rebase is running.
Hey Phillip,

Huh, I do have some of the files opened in Emacs! They're in background, but indeed, now that you mentioned I remember that Emacs keeps track of changes and invokes "git status" sometimes. Next time I see the bug, I'll try closing the files and see if it happens again.

Thanks for the insight!
-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
Previous: Phillip WoodNext: Jeff King
Message 11 of 14 in “Possible race condition with git-rebase + .git/index.lock”
  1. Sergio Durigan JuniorMar 11, 2019
  2. Eric SunshineMar 11, 2019
  3. Sergio Durigan JuniorMar 11, 2019
  4. Duy NguyenMar 12, 2019
  5. Sergio Durigan JuniorMar 12, 2019
  6. Elijah NewrenMar 12, 2019
  7. Sergio Durigan JuniorMar 12, 2019
  8. Elijah NewrenMar 12, 2019
  9. Sergio Durigan JuniorMar 12, 2019
  10. Phillip WoodMar 13, 2019
  11. Sergio Durigan JuniorMar 13, 2019
  12. Jeff KingMar 13, 2019
  13. Sergio Durigan JuniorMar 13, 2019
  14. MingunOct 28, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.