I followed the readme instructions for building Parity from source and then executed:
cargo build --release
~/.cargo/bin/cargo build --release
as instructed, both of which returned the following message while the prompt hung:
Blocking waiting for file lock on the registry index
I'm on a Mac.
Running cargo clean seems to fix the problem.
I had the same issue and got around it by using
rm -rf ~/.cargo/registry/index/*
I suggest looking at 'Cargo build hangs with " Blocking waiting for file lock on the registry index" after building parity from source' first.
This happens when you run two compilations of the same project at the same time. The compiler uses a lock file to avoid having data race issues.
There are some possibilities:
If you ran the two compilations yourself, the solution is obvious: you need to cancel one of them.
If you use an IDE that automatically compiles your project: you can wait for the job to be finished or close the IDE. If it does not work, this is probably because of RLS hanging out. You can run pkill rls to solve the issue.
As a last resort, you can force the removal of the lock using rm -rf ~/.cargo/registry/index/* as said in jvatic's answer.
It is important to ensure you have no other rls or cargo running.
sudo pkill rls cargo is a good way to ensure they are not.
Removing rm $CARGO_HOME/.package-cache worked for me.
I accidentally hit ctrl+z instead of ctrl+c while executing cargo run and the next execution of cargo run showed me Blocking waiting for file lock on the registry index. I removed the said file and then it worked again.
Edit:
If you accidentally hit ctrl+z like me, you can unsuspend the cargo run process by running fg instead of deleting the package cache file. ctrl+z actually sends a SIGTSTP signal to the process and that process will be suspended until you tell it to continue. See this answer for more info.
You usually get this error when you run the cargo build command twice at the same time. If you are using an IDE check if a plugin is running a cargo command in the background, this was the case for me with VS Code.
I am using this command in macOS Monterey 12.4:
rm -rf ~/.cargo/.package-cache
then rerun the build command, works.
My issue was the IDE was running cargo and had locked the directory. Try closing your IDE
My VSCode intellisense was working on a build. Make sure your intellisense is not builing. It displays a little gear icon spinning on bottom. Happens mostly when you update Cargo.toml
I fixed this issue by running the following commands:
Search for all rust related processes by $ ps aux | grep rls
Stop all of them one by one with $ sudo kill -9 <PID>
You can point your IDE to use a different path when building the code.
This will prevent conflicts with locks in the future. Add the following compile flags to the IDE:
--target-dir target/rls/
In VSCode use the following setting:
"rust-analyzer.runnables.extraArgs": [
"--target-dir",
"target/rls/"
]
Same issue in VScode : if you've installed RLS
File | Preferences | Settings
Search for "rls"
In "rust" extension, uncheck "Start RLS automatically when opening a file or project"
Re-open your project, and it should be solved.
Before removing the Cargo registry index as suggested in the accepted answer, make sure no other process is currently compiling Parity or any other Rust package.
it's work for me on the linux (ubuntu) :
$ rm ~/.cargo/.package-cache
I tried to create a Polkadot Node by following the Readme instructions.
I was able to build it by running the following commands (copy/paste into Bash Terminal):
git clone https://github.com/paritytech/polkadot;
cd polkadot; git checkout master;
rustup update nightly;
rustup target add wasm32-unknown-unknown --toolchain nightly;
rustup update stable;
rustup default stable;
cargo install --git https://github.com/alexcrichton/wasm-gc --force;
cargo install --git https://github.com/pepyakin/wasm-export-table.git --force;
brew install openssl; brew upgrade openssl;
rustc --version; cargo --version;
./build.sh;
cargo build;
cargo run -- --help;
./target/debug/polkadot --help;
I then tried to run a Polkadot Node with the following commands (which are equivalent):
./target/debug/polkadot -- --chain=dev --validator --key Alice -d /tmp/alice;
cargo run -- --chain=dev --validator --key Alice -d /tmp/alice;
But instead it showed the following:
Blocking waiting for file lock on the git checkouts
Blocking waiting for file lock on build directory
I found it was caused by CLion (Jetbrains IDE).
I solved the problem by closing CLion. I used Visual Studio Code editor instead, which also allows for debugging Rust code with breakpoints
if you ever hit "Blocking waiting for file lock on package cache",
Run the command below and run cargo again.
rm $CARGO_HOME/.package-cache
I had a case where there was an update to my rust extension rust-analyzer in vscode that was causing it. I updated and reloaded the extension and then cargo build ran fine.
Problem was another process using cargo. I could not find the process to kill so I restarted my local machine and it worked.
Finally. And I absolutely mean finally when all fails and you want a quick out. Restart your machine.
Perhaps it's also the rust-analyzer taking way too long so don't open vscode on reboot, use your terminal instead.
You Should Temporarily Stop the rls Process.
On the risk of coming late to the party, while cargo, rls or rust-analyzer are responsible for the lock to avoid data races.
An underlying issue maybe the number of inotify filewatchers.
Usually they work fine by spawning a new watcher and wait their turn but if they run out of watchers space this can be a problem.
Agreeing to all the above solutions but suggesting to check the number of max_user_watches
# view current settings
cat /proc/sys/fs/inotify/max_user_watches
# increasing it, /etc/sysctl.conf
fs.inotify.max_user_watches=524288
# The new value can then be loaded in by running s
$sudo sysctl -p.
What worked for me
For me, I found that the issue was caused by configuring my target dir:
[build]
target-dir = ".cargo/target"
in my .cargo/config.
What didn't work
I ran cargo build --release -vv and saw a message that didn't appear without the -vv flag:
Blocking waiting for file lock on build directory
I thought this a big clue so I tried stuff like disabling my file backups. I also tried all the answers on this page with no luck.
For me rust analyzer didn't stop and closing the IDE didn't help. But instead of shutting the computer just close the IDE and go into task manager (this is at least for windows). In task manager under details tab you can find any cargo processes that may be running and kill them there. Then you can reopen IDE and you should be back to normal.
I think you should use cargo clean and re-run the cargo run command and wait for some time. This usually happens when you try to use a new module in your code by adding it into Cargo.toml file.
Kill the cargo process that is running in the background, it should fix.
Had the same issue
Actually, on another terminal, I was running my debugger and that's why this command was blocked.
So just stopped the debugger and then ran the command and everything went fine.
I got the same problem when cargo run but nothing work for me i restart my system and problem fixed.
Windows: i opened the task manager and end the Cargos processes
In my case, I had Sourcetree running in the background, and it seems that was holding the file lock. Closing the app fixed the issue.
If you are sure that there is no other cargo process executing, but this problem still occur frequently, it might be your network problem.
I'm trying to force rpm to follow a given install order and it is not working as expected. The Requires clause I added is not being respected.
I am doing a bare-metal Linux installer (openSUSE 42.2-based). A whole system -- hundreds of packages -- are installed with one RPM command (using --root). I am having problems with three packages -- pam-config, pam-script, and openssh. The pam-config %post scriptlet tries to modify files contained in pam-script and openssh but is installed, by default, before them. It does not have dependencies by default, so, having the source, I rectified that by adding:
Requires: pam-script
Requires: openssh
to pam-config.spec. (I also tried Prereq: with same results.) As expected, with this change, it switches the ordering for pam-script and that error goes away. But it steadfastly refuses to change the order of installation for openssh, which is installed two packages after pam-config. [Openssh is dependent on coreutils and shadow (pwdutil), both of which are already installed at this point. It's also dependent (PreReq) on a mysterious macro, %{fillup_prereq}.]
Everything else installs (and runs) just fine, but I would like to understand better how rpm works. I thought if I used Required: to specify openssh in pam-config, that openssh would invariably be installed before pam-config. It worked for pam-script.
rpm -qp --requires on the .rpm file shows openssh. I repeated the install with the -vv option instead of -v. I can see the Requires: for openssh listed just the same as pam-script (YES (added provide)). I see a pam-config-0.91xxx -> openssh-7.2p2xxx listed under SCC #8: 11 members (100 external dependencies). I see the install of pam-config, which has no dependency information and nothing remarkable except for the %post scriptlet command that generates the error (pam-config --service sshd --delete --listfile). What other kind of things should I be looking at to debug this? What are these SCCs? Am I missing something about Requires? Or is there something obscure I may have overlooked, like circular, indirect, or hidden dependencies (I've checked for that, but ruled it out)? I've looked at several RPM tutorials and done a number of web searches and come up empty.
UPDATE: It appears that unlike pam-script, openssh is caught up in a mutual-dependency critical section. Here is the order of the packages actually being installed:
ruby2.1-rubygem-ruby-dbus-0.9.3-4.3.x86_64.rpm
pam-script-1.1.6-1.os42.gb01.x86_64.rpm
suse-module-tools-12.4-3.2.x86_64.rpm
kmod-17-6.2.x86_64.rpm
kmod-compat-17-6.2.x86_64.rpm
libcurl4-7.37.0-15.1.x86_64.rpm
pam-config-0.91-1.2.os42.gb01.x86_64.rpm
systemd-sysvinit-228-15.1.x86_64.rpm
krb5-1.12.5-5.13.x86_64.rpm
openssh-7.2p2-6.1.SBC.os42.gb01.x86_64.rpm
dracut-044-12.1.x86_64.rpm
systemd-228-15.1.x86_64.rpm
If I stage an installation on a production system and stop just before pam-config, it complains about being dependent on krb5, which is in the future! If I stop at ruby, it works. If I stop at pam-script, it works. If I stop at suse-module-tools, it complains about dependencies on dracut. So I'm wondering if RPM abandons its ordering principle within a mutual-dependency critical section, or if there is a dependency I haven't uncovered yet. I am using rpm -q --requires and rpm -q --provides to work this out. Stay tuned.
You can add more explicit sub-fields to the Requires tag, e.g. Requires(post): openssh-server or Requires(pre,post): openssh-server.
A single RPM transaction isn't really atomic, but is treated that way. Without this additional information, it just ensures that the packages are installed by the end of this transaction, which is "good enough" most of the time.
Another option is to put the required configuration into a %triggerin stanza, which I believe only executes once both packages are installed.
I want to install openjdk on ubuntu.
I found two ways to install it.
The first is typing "sudo apt-get install openjdk-8-jdk" on terminal.
The second is downloading the binary file such as *.tar.gz and then unpack the file and set environment variables JAVA_HOME&PATH.
So, is there any difference between this two methods?
I mean, will it cause different results?
Thanks a lot.
With the first approach, the installation is controlled by Debians Apt package manager and will receive updates, with the second one you will have to do that manually.
It will probably not end with different result.
On linux distributions you have what is called a packet manager : Yours (and on almost every ubuntu) is APT.
So the main difference is that when you use apt, you can "trust more" what you are downloading, because hopefully, content in apt are check.
However, because of this checking, apt isn't every time up-to-date, and it may induce some difference in version.
However, in my opinion if you doesn't want to duplicate file or pollute your system, you may want to choose either one option and stay with it : if you use apt, use apt to update, if you download it manually keep updating it manually.
I personally prefer to use apt when possible.
After repeated attempts and trying to google this issue I'm stuck and am looking for help from my fellow stackers.
Following the wiki from tcadmin I have to run the following commands
wget http://www.tcadmin.com/installer/mono-2.11.4-i386.rpm
yum -y install mono-2.11.4-i386.rpm --nogpgcheck
/opt/mono-2.11.4/bin/mozroots --import --sync --quiet
/opt/mono-2.11.4/bin/mono --aot -O=all /opt/mono-2.11.4/lib/mono/2.0/mscorlib.dll
for i in /opt/mono-2.11.4/lib/mono/gac/*/*/*.dll; do /opt/mono-2.11.4/bin/mono --aot -O=all $i; done
when I get to the yum part it fails and outputs this error.
file / from install of mono-2.11.4-bi.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
Most sites and places suggest using an override or force command but this sounds stupid and will probably cause issues down the road for myself and the system.
I have flagged a ticket with the company that supplies the wiki about this issue but I'm yet to have a reply.
Another suggestion was to extract the rpm and move the files one by one but this is quite time consuming..
The ticket was responed to with the following;
It is safe to force install because all files are placed in /opt/mono-2.11.4 but there is a bug with mono on centos 7 that prevents tcadmin from working correctly.
For anyone else who happens upon this thread, I'm pleased to report that while I didn't encounter this error installing mono (that was a whole other process) I did encounter it while trying to install TCAdmin itself, but I was able to complete the installation of TCAdmin on CentOS 7 after using rpmrebuild to modify the spec.
Simply install rpmrbebuild, run rpmrebuild -pe {packagename}.rpm, scroll down to the %files section and remove the lines for any offending directories (in my case, the '/' and '/home' directories), save and quit, press y, and note the result location. In my case, it was /root/rpmbuild/RPMS/noarch/{packagename}.rpm.
Traverse to that directory and run yum -y install ./{packagename.rpm and it will install without a hitch.
The same should also apply to any other packages that return the conflicts with filesystem error. Just adjust the package names in the above examples accordingly.
*Thanks to the venerable Ahmad Samir for pointing me in the right direction with his post in this thread.
I had the same issue trying to install Fluentd agent on CentOS 7:
(venv)[user#machine01 tmp]$ sudo rpm -ivh td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
file /opt from install of td-agent-2.1.1-0.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
I wouldn't say that downgrading your whole OS is the solution. Maybe an elegant workaround would be to rebuild the .rpm file in order to avoid those file systems which are making conflicts. You can do this by modifying the spec file with rpmrebuild command.
However, if you trust the software you are about to install or you want to try if works no matter what, then an easier (and faster) workaround is to force the rpm installation. That's what I did ...
(venv)[user#machine01 tmp]$ sudo rpm -ivh --force td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
Updating / installing...
1:td-agent-2.1.1-0 ################################# [100%]
adding 'td-agent' group...
adding 'td-agent' user...
Installing default conffile...
prelink detected. Installing /etc/prelink.conf.d/td-agent-ruby.conf ...
Configure td-agent to start, when booting up the OS...
...and it worked for me
(venv)[user#machine01 tmp]$ sudo systemctl start td-agent.service
(venv)[user#machine01 tmp]$ sudo systemctl status td-agent.service
td-agent.service - LSB: td-agent's init script
Loaded: loaded (/etc/rc.d/init.d/td-agent)
Active: active (running) since vie 2014-12-12 09:34:09 CET; 4s ago
Process: 17178 ExecStart=/etc/rc.d/init.d/td-agent start (code=exited, status=0/SUCCESS)
...
Hope it helps
This is an inherent issue with centos 7.
Going back to centos 6 fixed it.
I use lxde on Gentoo.
Versions of software:
lxappearance 0.5.2
lxde-common 0.5.5
lxde-icon-theme 0.5.0
lxinput 0.3.2
lxmenu-data 0.1.2
lxpanel 0.5.12
lxrandr 0.1.2
lxsession 0.4.6.1
lxsession-edit 0.2.0
lxshortcut 0.1.2
menu-cache 0.4.1
Time to time lxde exits from session to the session manager (I use slim-1.3.5). After it items reboot and halt disappear from the Logout menu and ck-list-sessions shows two sessions: one active and one not active.
System log near the problem: http://vpaste.net/zOZFl
The question is where can I try to look for the reason of this problem? Where does lxde store logs?
Check /var/log/Xorg.0.log.old for errors. It may be the X server that is restarting. Failing that, try starting X from the console using startx. You'll need to stop /etc/init.d/xdm first. If it still boots you out, you'll probably see some useful output. As a side note, I found slim to be a little unreliable but it's been a while since I tried it. I use lightdm now instead.