从源构建奇偶校验后，货物构建挂起并出现“阻止等待注册表索引上的文件锁定”

运行 cargo clean 似乎可以解决问题。

---

我遇到了同样的问题并通过使用解决了它

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

我建议先查看“Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source”。

---

当您同时运行同一个项目的两个编译时，就会发生这种情况。编译器使用锁定文件来避免出现数据竞争问题。

有一些可能性：

如果您自己运行这两个编译，则解决方案很明显：您需要取消其中一个。

如果您使用自动编译项目的 IDE：您可以等待作业完成或关闭 IDE。如果它不起作用，这可能是因为 RLS 挂起。您可以运行 pkill rls 来解决问题。

作为最后的手段，您可以使用 rm -rf ~/.cargo/registry/index/* 强制删除锁，如 jvatic 的回答中所述。

---

确保您没有其他 rls 或货物在运行，这一点很重要。 sudo pkill rls cargo 是确保它们不存在的好方法。

---

删除 rm $CARGO_HOME/.package-cache 对我有用。

我在执行 cargo run 时不小心点击了 ctrl+z 而不是 ctrl+c，而下一次执行 cargo run 时我看到了 Blocking waiting for file lock on the registry index。我删除了上述文件，然后它再次工作。

编辑：
如果您像我一样不小心点击了 ctrl+z，您可以通过运行 fg 来取消暂停 cargo run 进程，而不是删除包缓存文件。 ctrl+z 实际上向进程发送了一个 SIGTSTP 信号，并且该进程将被挂起，直到您告诉它继续。有关详细信息，请参阅此 answer。

---

当您同时运行两次 cargo build 命令时，通常会出现此错误。如果您使用 IDE 检查插件是否在后台运行 cargo 命令，我使用 VS Code 就是这种情况。

---

我的问题是 IDE 正在运行 cargo 并锁定了目录。尝试关闭你的 IDE

---

我的 VSCode 智能感知正在构建。确保你的智能感知没有建立。它显示一个在底部旋转的小齿轮图标。主要发生在您更新 Cargo.toml 时

---

VScode 中的相同问题：如果您已安装 RLS

文件 |偏好 |设置 搜索“rls” 在“rust”扩展名中，取消选中“打开文件或项目时自动启动 RLS”

重新打开您的项目，它应该得到解决。

---

我通过运行以下命令解决了这个问题：

通过 $ ps aux | 搜索所有与 rust 相关的进程grep rls 用 $ sudo kill -9 将它们一一停止

---

在按照接受的答案中的建议删除 Cargo 注册表索引之前，请确保当前没有其他进程正在编译 Parity 或任何其他 Rust 包。

---

我尝试按照 Readme 说明创建一个 Polkadot 节点。

我能够通过运行以下命令（复制/粘贴到 Bash 终端）来构建它：

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;

然后我尝试使用以下命令（等效）运行 Polkadot 节点：

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

但相反，它显示了以下内容：

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

我发现它是由 CLion（Jetbrains IDE）引起的。

我通过关闭 CLion 解决了这个问题。我改用 Visual Studio Code 编辑器，它还允许使用断点调试 Rust 代码

---

我在 macOS Monterey 12.4 中使用这个命令：

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

然后重新运行构建命令，工作。

---

如果您曾经点击“阻止等待包缓存上的文件锁定”，

运行下面的命令并再次运行 cargo。 rm $CARGO_HOME/.package-cache

---

最后。我绝对的意思是最后当一切都失败并且你想要快速退出时。重新启动您的机器。也许这也是 rust-analyzer 花费的时间太长，所以不要在重启时打开 vscode，而是使用你的终端。

---

它在 linux (ubuntu) 上对我有用：

$ rm ~/.cargo/.package-cache

---

您应该暂时停止 rls 进程。

---

关于聚会迟到的风险，而货物、rls 或 rust-analyzer 负责锁定以避免数据竞争。一个潜在的问题可能是 inotify filewatchers 的数量。

通常他们会通过产生一个新的观察者并等待轮到他们来正常工作，但如果他们用完了观察者空间，这可能是一个问题。同意上述所有解决方案，但建议检查 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.

---

问题是另一个使用货物的过程。我找不到要杀死的进程，所以我重新启动了本地机器并且它工作了。

---

什么对我有用

对我来说，我发现问题是由配置我的目标目录引起的：

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

在我的 .cargo/config 中。

什么没用

我运行 cargo build --release -vv 并看到一条没有 -vv 标志的消息：

Blocking waiting for file lock on build directory

我认为这是一个很大的线索，所以我尝试了禁用文件备份之类的方法。我也尝试了此页面上的所有答案，但没有运气。

---

对我来说，rust 分析器并没有停止，关闭 IDE 也无济于事。但是不要关闭计算机，只需关闭 IDE 并进入任务管理器（这至少适用于 Windows）。在详细信息选项卡下的任务管理器中，您可以找到任何可能正在运行的货物进程并在那里杀死它们。然后你可以重新打开IDE，你应该恢复正常。

---

在构建代码时，您可以指定 IDE 使用不同的路径。这将防止将来与锁发生冲突。将以下编译标志添加到 IDE：

--target-dir target/rls/

在 VSCode 中使用以下设置：

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

https://i.stack.imgur.com/IxElQ.png

---

我认为您应该使用 cargo clean 并重新运行 cargo run 命令并等待一段时间。当您尝试通过将新模块添加到 Cargo.toml 文件中来尝试在代码中使用新模块时，通常会发生这种情况。

---

如果你确定没有其他的cargo进程在执行，但是这个问题还是经常出现，可能是你的网络问题。

---