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

Rust Problem Overview

I followed the readme instructions for building Parity from source and then I execute this command:

cargo build --release

and then:

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

.. as instructed; both of which cause me to receive the following message while the prompt hangs:

 Blocking waiting for file lock on the registry index

I'm on a Mac.

Rust Solutions

Solution 1 - Rust

Running cargo clean seems to fix the problem.

Solution 2 - Rust

I had the same issue and got around it with rm -rf ~/.cargo/registry/index/*.

Edit: I suggest looking at this answer first.

Solution 3 - Rust

This happens when you run 2 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 2 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 just pkill rls to solve the issue.
As a last resort, you can remove the lock forcefully: rm -rf ~/.cargo/registry/index/* as said in another answer.

Solution 4 - Rust

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.

Solution 5 - Rust

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.

Solution 6 - Rust

You usually get this error when you run 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.

Solution 7 - Rust

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

Solution 8 - Rust

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

Solution 9 - Rust

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.

Solution 10 - Rust

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>

Solution 11 - Rust

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.

Solution 12 - Rust

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

Solution 13 - Rust

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

Solution 14 - Rust

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.

Solution 15 - Rust

You Should Temporarily Stop the rls Process.

Solution 16 - Rust

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.

Solution 17 - Rust

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

Solution 18 - Rust

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.

Solution 19 - Rust

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.

Solution 20 - Rust

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

Content Type	Original Author	Original Content on Stackoverflow
Question	Naruto Sempai	View Question on Stackoverflow
Solution 1 - Rust	Russel Winder	View Answer on Stackoverflow
Solution 2 - Rust	jvatic	View Answer on Stackoverflow
Solution 3 - Rust	Boiethios	View Answer on Stackoverflow
Solution 4 - Rust	Wilfried Kopp	View Answer on Stackoverflow
Solution 5 - Rust	bmdelacruz	View Answer on Stackoverflow
Solution 6 - Rust	Hom Bahrani	View Answer on Stackoverflow
Solution 7 - Rust	Ben	View Answer on Stackoverflow
Solution 8 - Rust	PPP	View Answer on Stackoverflow
Solution 9 - Rust	bendeg	View Answer on Stackoverflow
Solution 10 - Rust	Heartbit	View Answer on Stackoverflow
Solution 11 - Rust	q9f	View Answer on Stackoverflow
Solution 12 - Rust	Luke Schoen	View Answer on Stackoverflow
Solution 13 - Rust	Levit Kanner	View Answer on Stackoverflow
Solution 14 - Rust	Osoro	View Answer on Stackoverflow
Solution 15 - Rust	ax39T-Venom	View Answer on Stackoverflow
Solution 16 - Rust	Gabe	View Answer on Stackoverflow
Solution 17 - Rust	nilinswap	View Answer on Stackoverflow
Solution 18 - Rust	M-Cat	View Answer on Stackoverflow
Solution 19 - Rust	super IT guy	View Answer on Stackoverflow
Solution 20 - Rust	takeItIzzy	View Answer on Stackoverflow