Cargo build завис: "Blocking waiting for file lock" — как починить

Введение: когда компиляция Rust превращается в квест

Вы решили собрать Parity (или любой другой сложный Rust-проект) из исходников. Команда cargo build запущена, терминал молчит, а через минуту вы видите знакомое многим сообщение:

Blocking waiting for file lock on the registry index

Сборка зависает намертво. Ctrl+C не помогает, перезапуск терминала — тоже. Знакомо? Эта проблема — одна из самых популярных на Stack Overflow (тысячи просмотров), и сегодня мы разберем её до винтика.

В этой статье я, как ваш проводник в мир Rust, расскажу:
- Почему возникает эта ошибка?
- Как её исправить за 30 секунд?
- Как вообще не допустить её появления?
- И немного заглянем под капот Cargo.

Поехали! 🚀

Откуда берётся "Blocking waiting for file lock on the registry index"?

Для начала давайте переведём эту ошибку с языка Cargo на человеческий:

«Я, Cargo, хочу скачать или обновить список пакетов из реестра (registry), но не могу — файл блокировки уже занят другим процессом. Жду...»

В Rust экосистеме cargo использует файловые блокировки (.lock файлы), чтобы два процесса не пытались одновременно писать в кэш реестра (~/.cargo/registry). Это защищает от повреждения данных, но иногда блокировка «залипает».

Основные причины зависания

• Аварийное завершение предыдущей сборки — вы закрыли терминал, компьютер выключился или cargo build упал с ошибкой, но файл блокировки остался.
• Два экземпляра Cargo в одном проекте — запустили сборку в двух окнах терминала одновременно.
• Сборка Parity из исходников — этот проект тянет огромное количество зависимостей (сотни крейтов), и Cargo может подвисать на этапе индексации, особенно на слабых машинах или при медленном интернете.
• Проблемы с правами доступа — редко, но бывает, когда ~/.cargo принадлежит другому пользователю.
• Файловая система без поддержки блокировок — например, некоторые сетевые шары или WSL без корректной настройки.

5 способов решения (от быстрого к надёжному)

🔧 Способ 1: Убить процесс Cargo (самый быстрый)

Если вы уверены, что никакая другая сборка не запущена, просто завершите процесс, который держит блокировку.

Linux/macOS:

pkill cargo
# или жёстче:
killall -9 cargo

Windows (PowerShell):

Get-Process cargo | Stop-Process -Force

После этого запустите cargo build снова. В 80% случаев этого достаточно.

🔧 Способ 2: Удалить файл блокировки вручную

Если первый способ не помог, идём в директорию реестра и удаляем файл блокировки.

Путь:

# Linux/macOS
rm -f ~/.cargo/registry/.cache-lock
rm -f ~/.cargo/registry/.package-cache

# Windows (cmd)
del %USERPROFILE%\.cargo\registry\.cache-lock
del %USERPROFILE%\.cargo\registry\.package-cache

После этого Cargo при следующем запуске создаст новый файл блокировки. Важно: убедитесь, что не запущено других процессов Cargo, иначе вы рискуете повредить кэш.

🔧 Способ 3: Cargo clean — ядерный вариант

Если ничего не помогает, очищаем всё, что накопилось. Это удалит папку target и сбросит кэш зависимостей для текущего проекта. Следующая сборка будет дольше, но зато чистой.

cargo clean

После этого попробуйте собрать проект снова:

cargo build

Этот метод особенно полезен, если вы собирали Parity или другой проект с огромным деревом зависимостей — иногда блокировка возникает из-за повреждённого кэша конкретного крейта.

🔧 Способ 4: Проверить права доступа к ~/.cargo

Иногда проблема в том, что у текущего пользователя нет прав на запись в ~/.cargo/registry. Это бывает после установки Rust через sudo или при работе в контейнерах.

Исправляем:

sudo chown -R $(whoami) ~/.cargo
chmod -R u+rw ~/.cargo

На Windows проверьте, не установлен ли атрибут «Только чтение» на папку %USERPROFILE%\.cargo.

🔧 Способ 5: Отключить индексацию реестра (для продвинутых)

Если вы работаете в изолированной среде или с медленным интернетом, можно временно отключить автоматическое обновление индекса реестра. Для этого создайте файл ~/.cargo/config.toml (или %USERPROFILE%\.cargo\config.toml на Windows) со следующим содержимым:

[net]
offline = true

Это заставит Cargo работать только с уже закэшированными пакетами. Внимание: если зависимости ещё не скачаны, сборка упадёт с ошибкой. Этот метод подходит, если вы уже один раз успешно собрали проект.

Отключить обратно:

# просто удалите строку или закомментируйте
# [net]
# offline = true

Как избежать этой ошибки в будущем?

Лучшее лечение — профилактика. Вот несколько привычек, которые уберегут вас от «залипшей блокировки»:

1. Не запускайте несколько сборок одновременно в одной директории. Если нужно собрать два проекта — используйте разные терминалы и разные папки.
2. Используйте cargo build --release для финальной сборки — он оптимизирует код, но не влияет на блокировки. Просто не запускайте его параллельно с cargo build (debug).
3. Настройте лимит времени ожидания — добавьте в ~/.cargo/config.toml:

[net]
retry = 3
timeout = 30

Это заставит Cargo повторять попытки, если блокировка снимается в течение 30 секунд.

4. Регулярно чистите кэш — раз в месяц выполня