I'm running Sonatype Nexus 3 inside a docker container, with the following startup command:
docker run -d -p 80:8081 --ulimit nofile=65536:65536 --name nexus -v nexus-data:/nexus-data -e INSTALL4J_ADD_VM_PARAMS="-Xms4g -Xmx4g -XX:MaxDirectMemorySize=6717m -Djava.util.prefs.userRoot=${NEXUS_DATA}/javaprefs" sonatype/nexus3
After updating the docker image version from 3.30.0 to 3.40.1, I keep getting the following warnings regarding user prefs.
2022-07-18 13:14:45,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
2022-07-18 13:15:15,860+0000 WARN [Timer-0] *SYSTEM java.util.prefs - Could not lock User prefs. Unix error code 2.
As you can see from the startup command, the user prefs directory is inside the docker volume and at directory /nexus-data/javaprefs . I have tried looking for existing locks inside the directory, but found none. I've also tried completely deleting the directory and saw that the warning still came up and the folder itself wasn't being created by Nexus.
I honestly don't even know if this is an important issue or not, since there is little to no documentation about the user preferences folder.
Even a way to turn off the warning log which fires every 30s would be useful.
----UPDATE----
I've tried doing a clean installation of Nexus through Docker, following the simple instructions inside the github sonatype nexus3 docker repository, and still find these warnings.
I even tried on a different OS (Windwos instead of linux, through Docker Desktop) and with and without a volume for /nexus-data.
At this point I believe it to be a bug in a newer Nexus version.
TLDR: Adding -Djava.util.prefs.userRoot=/nexus-data/javaprefs should solve the problem, assuming the nexus data directory is at /nexus-data/.
Just had the same issue after upgrading from 3.38.1 to 3.42.0. After some investigation found that indeed the java.util.prefs.userRoot property got lost somewhere between those versions. The default value in the vanilla Nexus 3.38.1 is /nexus-data/javaprefs.
I've run into this serious error while committing, and created a bug report.
I keep getting this error on TortoiseGit operations:
git did not exit cleanly (exit code 128)
I've reinstalled the program, rebooted, and tried to clone a fresh repo from github - nothing seems to work. I also deleted %appdata%\Tortoise git folder ... I'm at a loss now. Any advice on how to proceed?
It's probably because your SSH key has been removed/revoked. Make a new one and add it to your GitHub account.
for me I simply had to add configure my git username and email with the following commands:
git config --global user.email "you#example.com"
git config --global user.name "Your Name"
If you're running windows 7:
I was trying to decide the best way to do this securely, but the lazy way is :
right-click the parent folder
click the "properties" button
click the "security" tab
click the "edit" button
click the group that starts with "Users"
click the checkbox that says "full control"
click all the OK's to close the dialogs.
I realize this might circumvent windows "security" features, but it gets the job done.
git-bash reports
fatal: Unable to create <Path to git repo>/.git/index.lock: File exists.
Deleting index.lock makes the error go away.
In my case a folder in my directory named as the git-repository on the server caused the failure.
Deleting index.lock worked for me
on win7 64:
git-gui gives a good answer: a previous git has crashed and left a lock file. Manually remove.
In my case, this was in .git/ref/heads/branchname.lock.
delete, and error 128 goes away. It surprises that tortoisegit doesn't give such an easy explanation.
In my case, it was because of the proxy. A proxy was needed in the corporate network and TortoiseGit / Git does not seems to automatically get information from Windows internet settings. Setting up the proxy address solved the issue.
For me, I tried to check out a SVN-project with TortoiseGit. It worked fine if I used TortoiseSVN though. (May seem obvious, but newcomers may stumble on this one)
In my case, I forgot to add git to the respository name at the end.
I did git revert a multiple times ,and it worked for me make sure un-check the files while reverting you need changes. Stash your changes and pull again.
I was having this same issue and I resolved it in the following way...
I have the NVIDIA "Tegra Android Development Pack" installed and it seems to also have a version of mysysgit.exe with it. TortoiseGit automatically found that installation location (instead of the standard git installation) and auto-populated it in the settings menu.
To correct this, go to: "Settings -> General" and there is a field for the path to mysysgit.exe. Make sure this is pointing to the correct installation.
An quick solution would be to create a new local directory for example c:\git_2014, In this directory rightklick and choose Git Clone
make sure the username and email fields are not empty in the config file. and try to clone to an empty directory. these steps worked for me.
although, it is a very old thread, recently I got this error, and in my case, the link was broken. When the link to GitHub was fixed, it worked.
What has worked for me:
Removing all offending branch related files from all folders in .git\ref and .git\logs
I have a development server on an EC2 instance. Mercurial is also installed.
The environment is using an Apache server working from /var/www/html.
As this is a development environment, I want each commit to the repository will also be copied to the Apache folder (so we can add changes and see them on the fly instead of both committing and then copying to environment.
Is there a simple way to do this?
Thanks!
OK - got it,
Simply need to auto update on trigger -
Edit a config file (i.e. /etc/mercurial/hgrc) and add an hook:
[hooks]
changegroup = hg update
Cheers!
I'm using rvmrc with the following text:
rvm_path=/local/rvm
(on Ubuntu 11.10) but trying to install gives an obscure error:
$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
Successfully checked out branch ''
Current branch master is up to date.
Successfully pulled (rebased) from origin
: No such file or directory
Any ideas?
You have no need at all to set $rvm_path. You're using a multi-user install. Please follow the explicit instructions for the Multi-User install at https://rvm.io and remove any existing installations, remove /etc/rvmrc, /etc/profile.d/rvm.sh, and $HOME/.rvmrc. Comment out any RVM sourcing lines in your .bash_profile, and .bashrc and log out of the machine then back in. Then reinstall correctly. Setting the rvm_path has never been a requirement of the installer UNLESS you already have a Multi-User working installation in place, and you want to attempt to use a per-user install with it. THEN you would preset the $rvm_path to $HOME/.rvm in your own $HOME/.rvmrc, log out then back in and then attempt the install again. BUT, that is not a supported installation type. Which is why 99.999% of users will not need to set rvm_path at all.
The real problem was that the git configuration for auto-converting line endings was not set correctly which prevented any installation from working. It had nothing to do with using rvmrc settings.
The fix for this is simple (and comes straight from the github help page):
$ git config --global core.autocrlf input
Line endings are important in linux and by forgetting that setting, everything the rvm-install script was pulling from github had \r\n endings. I made that change so long ago on my work machine, I didn't even remember it -- but it was not set on my home system.
I'll leave it up in case someone else has the same problem.
I've configured my hg repository according to the docs described here:
MultipleCommitters.
However, when I execute "hg update -C" to recreate the working copy locally, the file permissions have changed such that it eventually causes errors on push when other developers attempt to commit changes. Supposidly, when configured properly, hg update will preserve file permissions. Yet it doesn't appear to be doing so:
-rwxrwxr-x 1 root mercurial 2948 2010-06-24 15:27 .hg/store/data/src/public/index.php.i
vs. (actual source file, after deleting the working copy and recreating with "hg update -C")
-rw-r--r-- 1 root mercurial 820 2010-06-28 12:07 src/public/index.php
How can mercurial be configured such that when users create new files or modify existing files, the group and it's permissions are preserved?
UPDATE
2010.06.28
Here is a sample of the errors I'm seeing:
remote: resolving manifests
remote: getting src/configs/application.ini
remote: abort: Permission denied: /hg/repo/path/src/configs/application.ini
remote: warning: changegroup hook exited with status 255
remote: calling hook changegroup.notify: hgext.notify.hook
I had this same problem and solved it by setting the sticky bit on the remote repo directory.
chmod +s `find . -type d`
That will solve the problem that the OP ran into.
Which method exactly you've used? Describe more what is your setup.
Yes, mercurial does remember file permissions on commit. When you do hg update -C, it will recreate files with permissions that were set on last commit.
Your error message seems to be telling that repository files on repository server have wrong permissions/owner, so you cannot modify them with hg push. This could be because someone commited and pushed files as a different repository server user.
I would reccomend shared ssh method ( https://www.mercurial-scm.org/wiki/SharedSSH ): you set up separate user account for repository management, add developer's ssh public keys (you should restrict them to be used only with mercurial with specific repositories) and then use ssh://hguser#server/path/to/repository as an url.
BTW: by default mercurial doesn't run any hooks if a user used to do push/pull is not in trusted list. See trusted section in man hgrc.
BTW2: don't run any regular software as a root. use normal account for that.