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.
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.
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.
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.
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
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.
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.
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.
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:
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.
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.
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.
