Cargo does not recover from failed git update (File lock issue?) #2533
Comments
|
Please let me know if you need additional information, I'll try to provide everything which might come in handy. |
|
Hm when Cargo prints that it's blocking, are you sure that there are no other processes on the system that have that lock acquired? It may be the case that some Cargo may be spuriously running around in the background for example. |
|
Hm at least I can't think of any processes running that acquire this lock. Is there a good way to find out? Well I already tried:
|
|
Whoa lol if after a restart the directory is still locked then that's probably a bug in Cargo! Could you try running cargo with |
|
I can reproduce it also. RUST_LOG=debug: |
|
This is the changeset https://github.com/servo/servo/pull/10291/files, the dependency is added and cargo fails to update the .lock files it seems. |
|
Updating the lockfile (using |
|
Aha, thanks for the info @emilio! I've been able to reproduce locally with a small test case, I'll try to get a fix up quickly |
alexcrichton
added a commit
to alexcrichton/cargo
that referenced
this issue
Mar 30, 2016
Currently sources may acquire file locks to ensure that they're not tampered with while they're in use. We may load two sources to the same location, however, in the case of git repositories which need to be updated. Cargo will first load a locked version of the source and then may load an unlocked version, and these two loads currently deadlock. This commit tweaks the logic when updating a source to only update it after the previous source has been replaced. Closes rust-lang#2533
|
Ok, found a fix! |
|
Whoah, awesome! Thanks for the quick fix! :) |
|
Thank you :) |
bors
added a commit
that referenced
this issue
Apr 2, 2016
Replace existing sources before updating Currently sources may acquire file locks to ensure that they're not tampered with while they're in use. We may load two sources to the same location, however, in the case of git repositories which need to be updated. Cargo will first load a locked version of the source and then may load an unlocked version, and these two loads currently deadlock. This commit tweaks the logic when updating a source to only update it after the previous source has been replaced. Closes #2533
|
This happens for me when you fetched some packages as root, then later tried to build as non-root. You can verify this by running Solved by deleting FETCH_HEAD and rebuilding. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm currently trying to build servo, which uses cargo for this (Current nightly is used afaik).
When updating some git repositories servo depends on cargo fails (not always, but sometimes (I'm puzzled about this, but I think this might be another issue completely)).
After manually restarting the cargo build, cargo continues, but when it again handles the git repository it previously failed on it just prints "Blocking waiting for file lock on the git checkout" and waits there indefinitely.
I attached a full log of what I did.
cargo-lock.txt
When searching for this in the existing issues I found #2486, which is a quite recent pull request apparently concerning the same message I got. So maybe this might be related to that change.
The text was updated successfully, but these errors were encountered: