fatal: Unable to create `../index.lock`: File exists.

[Dich0tomy]

For some time now lazygit seems to bug all the time. I'm 100% sure that there are no other programs running in the background that could do some git operations.

I try to open lazygit from the terminal, but everytime I try to do any operation after that I get the error about the git lock. So I remove it by hand rm -rf .git/index.lock and get back to lazygit, same thing.

It doesn't matter if I do this from bare console or from the console inside neovim. Sometimes after deleting the index.lock file and getting back it works fine, only to complain again a usage later.

If I remove the file manually and then use git commands instead of using lazygit, everything works fine.

Windows, but I'm on WSL2 kali-linux Linux stacjonarny 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 GNU/Linux Lazygit version 0.34

[mark2185]

Do you by any chance have the automatic fetch enabled? (that's the default) Maybe it hangs and causes said issues.

[Dich0tomy]

@mark2185 I didn't change any settings, so yes, that's probable that I have it enabled. I'll try to disable it and I'll come back with the results.

[Dich0tomy]

@mark2185 I tried. It doesn't help same issue.

[mattmiller-daxko]

I'm getting the same issue and I would love a fix or a workaround

[mark2185]

@mattmiller-daxko could you specify your environment? E.g. OS, lazygit version?

If it's also on WSL2, I found this (no answer) and this (long thread, but the link is to the answer).

In short, I cannot reproduce this, and if you're both on WSL, I'd bet my two cents on WSL itself being the root of the problems, not lazygit.

[mattmiller-daxko]

I'm not using WSL. I'm on Windows 11 21H2 using Windows Terminal with cmder mini as my shell. Lazygit commit=367b0d331836c90c015bf0c45f88612f3d94d08a, build date=2022-07-20T09:27:56Z, build source=binaryRelease, version=0.35, os=windows, arch=amd64

[mark2185]

Does the same happen with v0.34?

[mattmiller-daxko]

Not that I ever noticed. It only started happening after upgrading to 0.35

[mark2185]

Then it might be a regression. @mattmiller-daxko would you be willing to downgrade to v0.34 to see if it keeps happening? Same goes for @B4mbus

I seem to recall something about subprocesses being changed, but can't put my finger on it.

cc @jesseduffield for visibility and ideas

[mattmiller-daxko]

I have downgraded to v0.34 and I don't seem to have this problem anymore. I used v0.34 for several weeks before upgrading without any issues so I think it probably is a regression but I will leave another comment if I run into this issue again.

I also appreciate the quick response on this. I really love this git tool and would hate to have to switch to anything else.

[Dich0tomy]

@mark2185 I was running lazygit 0.34 all along, so the version is probably not a problem for me.

[mark2185]

Uhhh, well then... try updating? 😅

[Dich0tomy]

@mark2185 Yeah I just upgraded it, nothing wrong so far, I'll report in a day or two.

[mattmiller-daxko]

I'm still having this issue with v0.35. However, downgrading to v0.34 seems to solve it for me. I even tried disabling automatic refresh as suggested above but that did not solve the problem.

[jesseduffield]

I'm getting this issue too on v0.35 (OSX). Quite annoying! Though for me I don't need to actually remove the lock file: I just retry the action and it works the second time.

Would be good if we were able to reproduce it reliably so I could write a failing test for it and fix it

[Dich0tomy]

I have 0.35 on both windows and linux and the issue doesn't occur... I don't know.

[mark2185]

Welp, fun while it lasted

[Dich0tomy]

So it seems the issue is not version related and is somewhere else in the deepest corners of lazygit. Again - I'm using lazygit 0.35 on windows, and sometimes lazygit 0.35 on WSL2 and so far so good, no errors no more. For others, they appear.

[Ryooooooga]

It happened in my environment (macOS) even with v0.34.

It seemed to be caused by tmux's pane-border-format (with git status) that was updating every second.

[n12o]

I had the same issue on the past versions and now have it again on v0.35

I've found that removing index file and reinstalling lazygit with scoop fixes the issue for me.

[jesseduffield]

I'm working on migrating integration tests to the new format and I've been able to somewhat consistently reproduce the error on this PR: https://github.com/jesseduffield/lazygit/pull/2329

by running:

go run cmd/integration_test/main.go cli pkg/integration/tests/file/discard_changes.go

That test goes through a list of files and removes them one by one. Maybe one in ten times I get the index.lock error. Conveniently for me the test runs fast so it doesn't take long to get it to fail.

Some notes from my investigation:

• If I run the text in sandbox mode (via go run cmd/integration_test/main.go cli --sandbox pkg/integration/tests/file/discard_changes.go) and the index.lock error appears, I can wait a second and then try again and it works. This means that some process was running and then successfully completed (as opposed to dying and leaving the index.lock file there).
• If I quit out of vscode I still get the issue (suggesting that it's lazygit itself, or some process I'm not aware of that's running a git command)
• The issue occurs at roughly the same file each time, I believe after I've run a git reset command
• The issue occurs even if I disable background routines (by returning early from the startBackgroundRoutines() function in pkg/gui/background.go)
• The issue occurs even if I force all commands to use the same mutex (see pkg/commands/oscommands/multi_mutex.go). That is: assuming my code is right, no two lazygit commands should run simultaneously.
• The issue occurs in sandbox mode even if I'm not trying to go super fast
• The issue occurs at roughly the same file each time (deleted-them.txt), right after doing a git reset on the prior file

[jesseduffield]

Has anybody had this issue since 0.39.3? We've added retry logic for when the index.lock file is temporarily in use

[jesseduffield]

Closing until somebody has the issue again

[Saafo]

Still meet this issue on 0.40.2.

My experience is that when this lock window appear, I exit lazygit, delete the index.lock file, and enter lazygit, then:

• If I stage one file by hitting space on one file, the lock window appears again.
• If I stage all files by hitting a, the lock window won't appear. Then if I hit a again to unstage, and stage one file, the lock window won't appear.

[jorgheymans]

Still seeing this in 0.40.2 as well.

[fightyz]

Still seeing this in 0.40.2 as well. Will this issue be re-open again?

[ysy]

Still seeing this in 0.40.2 as well.

commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=windows, arch=amd64, git version=2.34.1.windows.1

[Daedren]

Can confirm it's still happening

commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=darwin, arch=arm64, git version=2.43.0

[jorgheymans]

It seems that it's lazygit itself that creates the .git/index.lock file. I thought that maybe it's related to the version of git running on my system (Ubuntu LTS) but it's not the case. It's happening with both the LTS version 2.37 as well as latest 2.43.2.

I setup an audit for the file:

sudo auditctl -w /path/to/.git/index.lock -p w -k git-index-lock

Then when the bug is triggered i can see this :

ausearch git-index-lock

    │ time->Thu Mar  7 08:55:02 2024
  99   │ type=PROCTITLE msg=audit(1709798102.993:5255): proctitle=67697400616464002D2D006170702F66726F6E74656E642F7468656D65732F696D732F76696
       │ 57773
 100   │ type=PATH msg=audit(1709798102.993:5255): item=1 name="/path/to/repo/.git/index.lock" inode=11535492 dev=103:02 m
       │ ode=0100664 ouid=1000 ogid=1000 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
 101   │ type=PATH msg=audit(1709798102.993:5255): item=0 name="/path/to/repo/.git/" inode=11569583 dev=103:02 mode=040775
       │  ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
 102   │ type=CWD msg=audit(1709798102.993:5255): cwd="/path/to/repo"
 103   │ type=SYSCALL msg=audit(1709798102.993:5255): arch=c000003e syscall=257 success=no exit=-17 a0=ffffff9c a1=5615a583ce60 a2=800c2 a3=1
       │ b6 items=2 ppid=2598205 pid=2598291 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pt
       │ s0 ses=3 comm="git" exe="/usr/bin/git" subj=unconfined key="git-index-lock"

What may give a hint is that /usr/bin/git exited with code -17 ?

[stefanhaller]

@jorgheymans Thanks for that. It doesn't tell me much more, -17 seems to indicate that the git process died on a SIGSTOP signal, and I don't know what to make of that. Maybe someone with more Unix knowledge can figure out more?