Cargo should say which lock it waits on when run with --verbose

[WaffleLapkin]

Problem

Due to an unfortunate series of events (rust-analyzer OOM'ing after using >44GiB of RAM) I had cargo's package cache permanently locked. When I'd try to build something all I would see is this:

    Blocking waiting for file lock on package cache

(I had no cargo/r-a running at that point)

This is only semi-helpful -- it shows you what's the problem, but not how to fix it.

Proposed Solution

It would be nice if cargo would print the path to the lockfile. In this case that would be something like ~/.cargo/.package-cache and ~/.cargo/.package-cache-mutate (deleting those fixed the problem for me). It's probably better to only print those with --verbose, since usually you are actually waiting for another cargo process.

Notes

Upd: this can be even worse for other locks/in combination with other build systems.

Just not I had to figure out that the blocking/broken lock is actually .../rust-q/build/rust-analyzer/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/.cargo-lock.

[ChrisDenton]

Shouldn't the lock be automatically released when the process dies and the OS cleans up the fd?

[WaffleLapkin]

That would be a reasonable assumption, however it seems like this time it did not happen. I don't really have any knowledge on why it might have not been cleaned up. But it did happen with both cargo and bootstrap at the same time, so I assume something went wrong.

There is also this stack overflow question: https://stackoverflow.com/questions/47565203/cargo-build-hangs-with-blocking-waiting-for-file-lock-on-the-registry-index-a, where some people recommend deleting the file or say that it helped them. So I'd assume there are cases where the OS does not do the cleanup...