Bootstrap should better handle cases where the lock is hold by nobody

[WaffleLapkin]

Summary

I just saw this:

WARNING: build directory locked by process , waiting for lock

Which made me quite confused confused. is , the process? (not unheard of, I have a binary called ,) Is the process empty string?

The actual result is (most likely) that because rust-analyzer OOM'ed after using >44GiB of RAM today, the lock was not released and so is held by no process (thus, empty string).

Command used

x b proc-macro-srv-cli rustfmt --stage 0 --build-dir build/rust-analyzer

(although it does not matter)

Expected behaviour

Bootstrap explicitly saying that no process is holding the lock & possibly even suggesting removing the lockfile.

Operating system

NixOS

HEAD

99768c8

[jieyouxu]

I thought we changed this in #132737... That can happen if the PID is somehow not available
cc @clubby789 maybe you know a bit more about the dir lock?

[bjorn3]

The actual result is (most likely) that because rust-analyzer OOM'ed after using >44GiB of RAM today, the lock was not released and so is held by no process (thus, empty string).

We don't use the existence of a lockfile to indicate that another process is running. Rather we take an advisory lock on the lockfile. Advisory locks are automatically unlocked by the OS when the process that holds them exits for whatever reason.

Which made me quite confused confused. is , the process? (not unheard of, I have a binary called ,) Is the process empty string?

It prints the content of the lockfile which should contain the pid of the process that last locked it (even after said process exited).

[clubby789]

That's very strange. Maybe a race between two bootstrap processes;

P1: Creates lockfile and takes lock
P2: Reads (currently empty) lockfile
P1: Writes PID to file
P2: Fails to take lock, prints the empty file contents previously read

[clubby789]

We could probably fix this by being smarter and writing more atomically but since the PID is just for diagnostics, maybe we can just check .is_empty() before printing the first message

[WaffleLapkin]

We don't use the existence of a lockfile to indicate that another process is running. Rather we take an advisory lock on the lockfile. Advisory locks are automatically unlocked by the OS when the process that holds them exits for whatever reason.

That's weird, cause I'm sure there were no other processes running at the same time 🤔