Hi, Lauching Git Bug (v0.8.0) gives me this Error message: Error: the repository you want to access is already locked by the process pid 1138 I don't have any 1138 PID running, and Git is working fine (Guitar, Gitk, etc.) Is there a way to unlock ?

If you are sure there is no other process, you can delete .git/git-bug/lock.

But realistically, only another git-bug process would put a lock there, which begs the question: if there really is no other process running, why does git-bug think so?

The corresponding code is there: https://github.com/MichaelMure/git-bug/blob/1ae31b342b57ace44131f5ecd03c506814a25e62/util/process/process.go#L9

Admittedly, there is a TODO that could explain your problem, but you are the first one to report a problem with that.

Sorry, finally I made a reboot : it works now, but I don't know how to reproduce... So issue could be closed. I'll try a few tests, and then I'll send you a feedback if it succeeds.

Arnaud LE CAM (arnaudlecam) closed the bug 2 years ago

Here I reproduced: First, you run git-bug: here .git/git-bug/lock contains the PID (ex.: 1322). The save all your works and close all youre running tasks (but you don't close git-bug). Now if you hard-reboot (pressing "Off" button a long time) while running git-bug, then git-bug is killed and .git/git-bug/lock isn't deleted (containing the killed PID: 1322). Now you reboot, but you don't start with git-hub : you run another programms and don't close them, until those PID's are greater than the killed PID (ex.: you can launch chromium and open a large number of tabs). With (un)luck, it will open a process with the same PID (1322). Then you launch git-hub, and it's reproduced (ex.: Error: the repository you want to access is already locked by the process pid 1322). The first time I reported it, I was realy unlucky: after hard-reboot, I think the "killed PID" was owned by a system's process so it wasn't listed with ps -e. May it should test the PID's name to ? If the PID is found, then we check this PID's name. And if the PID's name is "git-bug", then git-bug isn't launched, else git-bug could be launched.

Arnaud LE CAM (arnaudlecam) opened the bug 2 years ago

That's a very good point. I suppose we need a reliable and multi-platform way to check that the running process is indeed git-bug. Now, how to do that ...

May process.Name or process.NameWithContext should do the trick ? But sorry, I never wrote a Go line: you should be more efficient than me ;-)

I'm busy with other things, so anyone would be faster than that :-)

That's a pretty crazy path to a bug - I'm running Linux so I never hard kill anything (or reboot for that matter). What OS are you running and when you say that you start git-bug but don't close it, do you mean termui or webui (running the git-bug CLI should stop on it's own and delete the lock file).

I did a bit of testing (Xubuntu Linux 22.04) and found that the lock file is not always removed when I would have expected:

I wouldn't expect that we can capture SIGKILL but the webui could be enhanced to cleanly shut down on SIGTERM. Note that it's also possible that the longer running CLI processes (e.g. bridge pull) could leave a lock file behind when killed so I think the idea of checking that the process is in fact git-bug is a good idea.

That's a pretty crazy path to a bug - I'm running Linux so I never hard kill anything (or reboot for that matter). What OS are you running and when you say that you start git-bug but don't close it, do you mean termui or webui (running the git-bug CLI should stop on it's own and delete the lock file).

I'm runnig Linux (6.1.12-arch1-1), using termui. I understand your comment about that "crazy path to a bug": first time I reported this issue, my computer has halted with a power breakdown. I suppose it can be a "real case", so hardrebooted to try reproduce and reporting it as an issue.

Michael Muré (MichaelMure) closed the bug 2 years ago

Michael Muré (MichaelMure) opened the bug 2 years ago

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

I think the confusion here stems from the error message telling the user the PID of the process that owns the lock file (which can become stale or inaccurate). Checking for a process by name is a difficult problem to solve for accurately.

I think the right thing to do here would be to change the approach and altogether avoid trying to be smart: if a lock file exists, error out (optionally, we could prompt the user and ask if they want to remove it, or otherwise add a git bug unlock command to do that for them).

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 10 months ago

github-actions (github-actions) removed label lifecycle/stale 10 months ago

sudoforge removed label lifecycle/dormant 7 months ago