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

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

@Gordon01 provided an implementation for this in #15486.

@weihanglo commented:

Unsure if the discoverability of this behind --verobse. Personally I am fine with just printing the lock path unconditionally,

For me, this is too low level of a detail to be shown by default.

I do wonder what should be our bar for -v vs -vv vs CARGO_LOG.

Unsure if the discoverability of this behind --verobse

I agree. Without prior knowledge its hard to discover.

Personally I am fine with just printing the lock path unconditionally

Yes, but in 99,9% it's a garbage cluttering the output which is definitely a bad UX.

For me, this is too low level of a detail to be shown by default.

Agree.

The only good idea I have is to print path after some delay (say 5 seconds).

The only good idea I have is to print path after some delay (say 5 seconds).

I would love to see something like this, with some more details like who is holding the lock.

with some more details like who is holding the lock.

I've discovered that lock files are currently empty. I propose saving a process ID inside, possibly with an acquisition timestamp.

A PID alone would be sufficient to easily determine if a process is still running. While waiting for a lock, I could periodically print a status like {running, stopped}. Alternatively, we could simply print the raw PID if we prefer a minimal approach. Since this code would rarely execute, simple makes sense.

Another option would be to also save a timestamp. In this case, the file should be structured as JSON (or TOML), for example:

{ "pid": 12345, "timestamp": "2025-05-13T22:00:00Z" }

The status message could then display:

Blocking waiting for file lock on package cache held by PID 12345, running for 45s (/home/user/.cargo/.package-cache)

My plan is to write metadata in cargo::util::flock::Filesystem methods like open_rw_exclusive_create().

Currently, cargo::util::flock::Filesystem::open() returns (PathBuf, File), but since it's only used for lockfiles, would it make more sense to return a FileLock instead? This would allow adding a method to write PID metadata. Here's how open_rw_exclusive_create() might look:

pub fn open_rw_exclusive_create<P>(
    &self,
    path: P,
    gctx: &GlobalContext,
    msg: &str,
) -> CargoResult<FileLock>
where
    P: AsRef<Path>,
{
    let mut opts = OpenOptions::new();
    opts.read(true).write(true).create(true);
    let mut lock = self.open(path.as_ref(), &opts, true)?;
    acquire(
        gctx,
        msg,
        lock.path(),
        &|| try_lock_exclusive(lock.file()),
        &|| lock_exclusive(lock.file()),
    )?;
    // Write PID/timestamp after acquiring the lock
    let _ = lock.write_metadata();
    Ok(lock)
}

Open Questions

• What would be a sensible delay before showing lock wait messages?
• Should we store just the PID in plaintext, or use a structured format with additional fields like timestamp?
• Should we handle stale locks?

Attaching some extra data sounds good. I know that PostgreSQL does that in the postmaster.pid file. We can start small from pid, and expand to more information if needed. Note that this should be advisory only.

• What would be a sensible delay before showing lock wait messages?

It varies. Also depends on how focused people can be these day 😆. I would love to try like 15s to start with, but I don't really now.

• Should we store just the PID in plaintext, or use a structured format with additional fields like timestamp?

I would recommend JSON so we have room to expand it in the future. Also easy to parse without needing to look at any bespoke format.

• Should we handle stale locks?

We could clean up the content before unlock, though as it is advisory only it is fine as well if we don't want to.