Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source

Question

I followed the readme instructions for building Parity from source and then executed:

cargo build --release
~/.cargo/bin/cargo build --release

as instructed, both of which returned the following message while the prompt hung:

 Blocking waiting for file lock on the registry index

I'm on a Mac.

The problem for me was that my rust-analyzer vscode plugin was indexing. Once it finished, running `cargo run` worked fine. — oriont, Feb 11 '22 at 22:17
I've the same problem on Linux when using Rustler to use Rust codes in Elixir. The problem resolved by removing `~/.cargo/.package-cache` as mentioned it this issue https://github.com/rust-lang/cargo/issues/9742. — Ali Shirvani, Apr 03 '22 at 02:18
My problem was that I installed both Rust and rust-analyzer on VS Code at the same time. The problem was fixed after I removed either of the extensions. Hope this helps! — user3670684, Jun 25 '22 at 12:12
VSCode was my hang up as @oriont stated. I just needed to wait for the rust-analyzer to finish whatever it was doing. — Alan Richards, Nov 04 '22 at 17:08
I'm sure this will only apply to a small percentage of users, but for me, restarting Visual Studio Code fixed the problem — John Miller, Nov 23 '22 at 23:43
@oriont is right. I encountered this problem when my rust-analyser is indexing. — intlsy, Apr 06 '23 at 00:27
I had the same problem as @oriont. The rust-analyzer extension for VSCode was busy. As soon as it finished, my `cargo run` command proceeded. — Trevor Sullivan, Jun 29 '23 at 04:43

score 218 · Answer 1 · answered Apr 03 '18 at 16:01

218

Running cargo clean seems to fix the problem.

answered Apr 03 '18 at 16:01

Russel Winder

3,436
1
17
12

8

Seems less hacky, but for some reason only the accepted answer solved my problem. Is it doing the same? – Felix Jassler May 04 '19 at 17:36
3

@FelixJassler No. It deletes the entire target folder of the project you run this command for, unlike the accepted answer. – Prajwal Aug 22 '19 at 05:08
must note this for next time! Had already done the manual remove of the `~/.cargo/.package-cache` per @ali-shirvani and it worked a treat – mud Aug 13 '23 at 19:24
that's how I got it. I.e. Ran "cargo clean" and then build stuck on "Blocking waiting for file lock on package cache" – user656449 Aug 21 '23 at 19:49
worked for me. I'm using it in a devcontainer which seems to screwed things up when building it the first time. Cargo clean did the job tho. – Steven Aug 23 '23 at 19:12

score 209 · Accepted Answer · edited May 11 '23 at 16:53

209

I had the same issue and got around it by using

rm -rf ~/.cargo/registry/index/* ~/.cargo/.package-cache

I suggest looking at 'Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source' first.

edited May 11 '23 at 16:53

tadman

208,517
23
234
262

answered Dec 17 '17 at 13:57

jvatic

3,485
2
20
27

6

Worked for me after 30s of waiting, without doing anything. – Helin Wang Jun 23 '19 at 22:43
120

I had to remove `~/.cargo/.package-cache` as well. – tadman Nov 20 '20 at 01:43
28

For me, I suspect it's the `rust-analyzer` extension in VS Code. While it's downloading its components (after I open the project) I get the blocking problem. – sakura-bloom Dec 10 '21 at 10:43
4

worked for me after deleting both `.cargo/registry/index` and `.package-cache` – Emad Baqeri Apr 21 '22 at 21:37
I removed `rm -rf ~/.cargo/registry/cache/*` for Error `Blocking waiting for file lock on package cache` to make it work. – Rohit Kaushal Jun 26 '22 at 06:13
This answer should be updated to include what @tadman added. – Janos May 11 '23 at 10:22
It works, but I have to run those commands multiples times during the day... There is no long-term solution ? – Adri HM Aug 19 '23 at 10:03

score 160 · Answer 3 · edited Jun 07 '22 at 22:29

160

This happens when you run two compilations of the same project at the same time. The compiler uses a lock file to avoid having data race issues.

There are some possibilities:

If you ran the two compilations yourself, the solution is obvious: you need to cancel one of them.
If you use an IDE that automatically compiles your project: you can wait for the job to be finished or close the IDE. If it does not work, this is probably because of RLS hanging out. You can run pkill rls to solve the issue.
As a last resort, you can force the removal of the lock using rm -rf ~/.cargo/registry/index/* as said in jvatic's answer.

edited Jun 07 '22 at 22:29

the Tin Man

158,662
42
215
303

answered Oct 30 '18 at 14:09

Boiethios

38,438
19
134
183

29

This is correct, in my case it was the cargo extension in VS Code which was automatically compiling my project – Hom Bahrani Jul 14 '20 at 10:22
1

Same as @HomamBahrani. I think this answer reveal the root cause should be ranked higher. – June Wenston Aug 04 '20 at 08:13
My apologizes but where is this .cargo/registry/index/ located? I can't seem to find it in the project directory, the only folders there are src, target and .gitignore – Abdullah Ashraf May 31 '21 at 16:54
@AbdullahAshraf It's not in your project, it's in your home, like `/home/user/.cargo/registry/index` – Boiethios May 31 '21 at 17:57
@Boiethios Thanks for helping out. I forgot to mention but I'm on windows. Also, it worked after waiting for about 3-5 minutes. Since then, there was no wait. – Abdullah Ashraf Jun 01 '21 at 18:12

score 69 · Answer 4 · answered Aug 17 '19 at 15:24

69

It is important to ensure you have no other rls or cargo running. sudo pkill rls cargo is a good way to ensure they are not.

answered Aug 17 '19 at 15:24

Wilfried Kopp

991
7
5

5

In my case it was just the cargo process that was still running. Killing that process fixed it for me. – gijswijs Dec 17 '21 at 03:53
2

For me, neither the most popular answer nor the accepted answer worked. But this worked. – Prajwal May 26 '22 at 04:47
1

This answer needs to be on the top – Haseeb Saeed Sep 20 '22 at 11:59
This saved me lots of hours, the other answers not worked for me but this. – Emad Baqeri Oct 08 '22 at 15:55

bmdelacruz · Answer 5 · 2022-01-01T03:49:14.640

41

Removing rm $CARGO_HOME/.package-cache worked for me.

I accidentally hit ctrl+z instead of ctrl+c while executing cargo run and the next execution of cargo run showed me Blocking waiting for file lock on the registry index. I removed the said file and then it worked again.

Edit:
If you accidentally hit ctrl+z like me, you can unsuspend the cargo run process by running fg instead of deleting the package cache file. ctrl+z actually sends a SIGTSTP signal to the process and that process will be suspended until you tell it to continue. See this answer for more info.

edited Jan 01 '22 at 03:49

answered Sep 29 '19 at 22:27

bmdelacruz

2,366
1
19
26

I have closed my IDE while compiling. This solution was fixed my issue. – Ramesh Kithsiri HettiArachchi Jan 10 '20 at 18:41
Yup, I had `^Z` inside Neovim and it must have been in the middle of some `cargo check` (or similar) pass when I did so. – Bo Jeanes May 18 '20 at 06:25
This worked in windows for me. – nck May 14 '23 at 22:08

score 29 · Answer 6 · answered Jun 02 '22 at 04:56

29

I am using this command in macOS Monterey 12.4:

rm -rf ~/.cargo/.package-cache

then rerun the build command, works.

answered Jun 02 '22 at 04:56

Dolphin

29,069
61
260
539

1

In my case, it's the correct solution. – Thinsky Dec 06 '22 at 05:08
Works for me too. – Samuel Santos May 23 '23 at 00:01

score 21 · Answer 7 · edited Jun 07 '22 at 22:30

21

You usually get this error when you run the cargo build command twice at the same time. If you are using an IDE check if a plugin is running a cargo command in the background, this was the case for me with VS Code.

edited Jun 07 '22 at 22:30

the Tin Man

158,662
42
215
303

answered Aug 23 '19 at 17:24

Hom Bahrani

3,022
27
25

score 18 · Answer 8 · answered Oct 05 '19 at 14:22

18

My issue was the IDE was running cargo and had locked the directory. Try closing your IDE

answered Oct 05 '19 at 14:22

Fuji

28,214
2
27
29

score 12 · Answer 9 · answered Sep 28 '20 at 04:30

12

My VSCode intellisense was working on a build. Make sure your intellisense is not builing. It displays a little gear icon spinning on bottom. Happens mostly when you update Cargo.toml

answered Sep 28 '20 at 04:30

PPP

1,279
1
28
71

score 11 · Answer 10 · answered Jul 11 '22 at 08:14

11

You can point your IDE to use a different path when building the code. This will prevent conflicts with locks in the future. Add the following compile flags to the IDE:

--target-dir target/rls/

In VSCode use the following setting:

"rust-analyzer.runnables.extraArgs": [
  "--target-dir",
  "target/rls/"
]

answered Jul 11 '22 at 08:14

Ralph Bisschops

1,888
1
22
34

This doesn't help, because cargo still stores and reads the global package cache in the `~/.cargo` directory, not in the current project's target directory. – gmoshkin May 25 '23 at 11:23
worked for me on ubuntu 22 with tauri app – Back2Lobby Jun 04 '23 at 15:09

score 7 · Answer 11 · answered Aug 18 '21 at 13:22

7

I fixed this issue by running the following commands:

Search for all rust related processes by $ ps aux | grep rls
Stop all of them one by one with $ sudo kill -9 <PID>

answered Aug 18 '21 at 13:22

Heartbit

1,698
2
14
26

This is what happened to me. The rustc process was not responding and locking the directory. None of the other answers worked and came here to add a reply explaining the same. – Emilio Mar 25 '22 at 16:00
The PID changes before you get a chance to kill it – Luke Schoen Mar 13 '23 at 04:29
@LukeSchoen the PID isn't changing, the process is restarting or being respawned with a new PID. Try `sudo pkill rls cargo` which finds and kills all instances. – robrecord Aug 23 '23 at 10:53

score 6 · Answer 12 · answered Aug 02 '20 at 19:20

6

Same issue in VScode : if you've installed RLS

File | Preferences | Settings
Search for "rls"
In "rust" extension, uncheck "Start RLS automatically when opening a file or project"

Re-open your project, and it should be solved.

answered Aug 02 '20 at 19:20

bendeg

196
2
8

score 5 · Answer 13 · answered May 25 '22 at 10:58

5

it's work for me on the linux (ubuntu) :

$ rm ~/.cargo/.package-cache

answered May 25 '22 at 10:58

Mahdad

788
6
8

score 5 · Answer 14 · answered May 16 '23 at 07:10

5

This helped to resolve the issue rm ~/.cargo/.package-cache

Blocking started after I added rand = "0.8.5" to my cargo.toml.

answered May 16 '23 at 07:10

Chukwudi Nweze

91
1
2

score 4 · Answer 15 · edited Mar 04 '18 at 21:10

4

Before removing the Cargo registry index as suggested in the accepted answer, make sure no other process is currently compiling Parity or any other Rust package.

edited Mar 04 '18 at 21:10

Shepmaster

388,571
95
1,107
1,366

answered Feb 08 '18 at 09:37

q9f

11,293
8
57
96

score 4 · Answer 16 · answered Jul 17 '18 at 18:52

I tried to create a Polkadot Node by following the Readme instructions.

I was able to build it by running the following commands (copy/paste into Bash Terminal):

git clone https://github.com/paritytech/polkadot;
cd polkadot; git checkout master;
rustup update nightly;
rustup target add wasm32-unknown-unknown --toolchain nightly;
rustup update stable;
rustup default stable;
cargo install --git https://github.com/alexcrichton/wasm-gc --force;
cargo install --git https://github.com/pepyakin/wasm-export-table.git --force;
brew install openssl; brew upgrade openssl;
rustc --version; cargo --version;
./build.sh;
cargo build;
cargo run -- --help;
./target/debug/polkadot --help;

I then tried to run a Polkadot Node with the following commands (which are equivalent):

./target/debug/polkadot -- --chain=dev --validator --key Alice -d /tmp/alice;
cargo run -- --chain=dev --validator --key Alice -d /tmp/alice;

But instead it showed the following:

Blocking waiting for file lock on the git checkouts
Blocking waiting for file lock on build directory

I found it was caused by CLion (Jetbrains IDE).

I solved the problem by closing CLion. I used Visual Studio Code editor instead, which also allows for debugging Rust code with breakpoints

The short answer is: If you have a Jetbrains IDE open, try closing it. Happened to me on Linux + IDEA. — JNissi, Aug 16 '18 at 05:24

Ayoub Boumzebra · Answer 17 · 2022-12-16T09:12:25.947

4

Windows: i opened the task manager and end the Cargos processes

edited Dec 16 '22 at 09:12

answered Dec 15 '22 at 22:40

Ayoub Boumzebra

3,885
3
21
37

score 3 · Answer 18 · answered Jul 16 '20 at 13:15

3

if you ever hit "Blocking waiting for file lock on package cache",

Run the command below and run cargo again. rm $CARGO_HOME/.package-cache

answered Jul 16 '20 at 13:15

Levit Kanner

121
1
8

score 3 · Answer 19 · answered Sep 26 '22 at 14:20

3

I had a case where there was an update to my rust extension rust-analyzer in vscode that was causing it. I updated and reloaded the extension and then cargo build ran fine.

answered Sep 26 '22 at 14:20

Yathi

1,011
1
12
21

score 1 · Answer 20 · answered Nov 07 '21 at 05:48

1

Problem was another process using cargo. I could not find the process to kill so I restarted my local machine and it worked.

answered Nov 07 '21 at 05:48

nilinswap

1,226
1
10
17

score 1 · Answer 21 · answered Nov 22 '21 at 23:56

What worked for me

For me, I found that the issue was caused by configuring my target dir:

[build]
target-dir = ".cargo/target"

in my .cargo/config.

What didn't work

I ran cargo build --release -vv and saw a message that didn't appear without the -vv flag:

Blocking waiting for file lock on build directory

I thought this a big clue so I tried stuff like disabling my file backups. I also tried all the answers on this page with no luck.

score 1 · Answer 22 · answered Jan 12 '22 at 14:42

1

Finally. And I absolutely mean finally when all fails and you want a quick out. Restart your machine. Perhaps it's also the rust-analyzer taking way too long so don't open vscode on reboot, use your terminal instead.

answered Jan 12 '22 at 14:42

Osoro

382
3
8

score 1 · Answer 23 · answered Jul 19 '22 at 20:19

1

I think you should use cargo clean and re-run the cargo run command and wait for some time. This usually happens when you try to use a new module in your code by adding it into Cargo.toml file.

answered Jul 19 '22 at 20:19

Ankit Kumar

403
3
8

score 1 · Answer 24 · answered Nov 13 '22 at 08:24

1

I got the same problem when cargo run but nothing work for me i restart my system and problem fixed.

answered Nov 13 '22 at 08:24

Harsh Mangalam

1,116
1
10
19

score 0 · Answer 25 · answered Aug 17 '20 at 16:57

0

You Should Temporarily Stop the rls Process.

answered Aug 17 '20 at 16:57

ax39T-Venom

32
1
5

1

There is an existing answer that covers this. Can you expand on this answer? – Jason Aller Aug 17 '20 at 23:41

score 0 · Answer 26 · answered Feb 13 '21 at 07:15

On the risk of coming late to the party, while cargo, rls or rust-analyzer are responsible for the lock to avoid data races. An underlying issue maybe the number of inotify filewatchers.

Usually they work fine by spawning a new watcher and wait their turn but if they run out of watchers space this can be a problem. Agreeing to all the above solutions but suggesting to check the number of max_user_watches

# view current settings
cat /proc/sys/fs/inotify/max_user_watches

# increasing it, /etc/sysctl.conf
fs.inotify.max_user_watches=524288

# The new value can then be loaded in by running s
$sudo sysctl -p.

score 0 · Answer 27 · answered Mar 10 '22 at 20:59

For me rust analyzer didn't stop and closing the IDE didn't help. But instead of shutting the computer just close the IDE and go into task manager (this is at least for windows). In task manager under details tab you can find any cargo processes that may be running and kill them there. Then you can reopen IDE and you should be back to normal.

score 0 · Answer 28 · answered Oct 21 '22 at 13:00

0

Kill the cargo process that is running in the background, it should fix.

answered Oct 21 '22 at 13:00

G il

11
1

score 0 · Answer 29 · answered Nov 09 '22 at 13:59

0

Had the same issue

Actually, on another terminal, I was running my debugger and that's why this command was blocked. So just stopped the debugger and then ran the command and everything went fine.

answered Nov 09 '22 at 13:59

ShoaibShebi

59
1
5

score -3 · Answer 30 · answered Sep 02 '20 at 15:27

-3

If you are sure that there is no other cargo process executing, but this problem still occur frequently, it might be your network problem.

answered Sep 02 '20 at 15:27

takeItIzzy

327
2
7

Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source

30 Answers30

What worked for me

What didn't work

Linked