CODEWITHSUNDEEP
rustrust-cargo
Naruto Sempai
Naruto Sempai

Reputation: 7201

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

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.

Upvotes: 299

Views: 170729

Answers (25)

arafat877
arafat877

Reputation: 27

the must fast way is to update your rustc compiler :

rustup update stable

I was facing a such situation, but then I updated my rustc, the problem has been resolved.

Upvotes: -1

Luke Schoen
Luke Schoen

Reputation: 4513

On macOS Sonoma 14.1.1, the way I fixed Blocking waiting for file lock on the registry index when I was trying to run cargo build was to open the Activity Monitor application:

  • Press CMD + Space, then type "Activity Monitor.app"
  • Click the CPU tab, and enter "cargo" in the search input field at the top right. enter image description here
  • Select all processes with "cargo" in the "Process Name" column
  • Click the (X) icon and choose "Force Quit" those processes
  • Wait for about a minute or so for those cargo processes to quit
  • Re-run your cargo build command without it hanging.

Note: I tried other solutions like quitting VSCode but that wasn't the cause in my situation.

Upvotes: 3

jvatic
jvatic

Reputation: 4036

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

I had the same issue and had success with a quick and dirty

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

Upvotes: 263

Chukwudi Nweze
Chukwudi Nweze

Reputation: 151

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

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

Upvotes: 5

Ayoub BOUMZEBRA
Ayoub BOUMZEBRA

Reputation: 5003

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

enter image description here

Upvotes: 7

Yathi
Yathi

Reputation: 1041

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.

Upvotes: 4

Ankit Kumar
Ankit Kumar

Reputation: 496

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.

Upvotes: 1

Ralph Bisschops
Ralph Bisschops

Reputation: 2518

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/"
]

enter image description here

Upvotes: 12

Hom Bahrani
Hom Bahrani

Reputation: 3542

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.

Upvotes: 22

Boiethios
Boiethios

Reputation: 42759

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.

Upvotes: 174

Dolphin
Dolphin

Reputation: 38733

I am using this command in macOS Monterey 12.4:

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

then rerun the build command, works.

Upvotes: 31

Mahdad
Mahdad

Reputation: 828

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

$ rm ~/.cargo/.package-cache

Upvotes: 5

bmdelacruz
bmdelacruz

Reputation: 2956

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.

Upvotes: 41

Marcin
Marcin

Reputation: 104

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.

Upvotes: 1

nilinswap
nilinswap

Reputation: 1514

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

Upvotes: 2

Heartbit
Heartbit

Reputation: 1836

I fixed this issue by running the following commands:

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

Upvotes: 7

Gabe
Gabe

Reputation: 111

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.

Upvotes: 0

PPP
PPP

Reputation: 1850

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

Upvotes: 12

bendeg
bendeg

Reputation: 326

Same issue in VScode : if you've installed RLS

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

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

Upvotes: 6

Levit Kanner
Levit Kanner

Reputation: 121

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

Upvotes: 3

Fuji
Fuji

Reputation: 29824

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

Upvotes: 19

Wilfried Kopp
Wilfried Kopp

Reputation: 1101

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.

Upvotes: 78

Luke Schoen
Luke Schoen

Reputation: 4513

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

Upvotes: 3

Russel Winder
Russel Winder

Reputation: 3794

Running cargo clean seems to fix the problem.

Upvotes: 248

q9f
q9f

Reputation: 11824

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.

Upvotes: 4

Related Questions