i am trying to setup Redisjson on redis-server
git clone https://github.com/RedisLabsModules/rejson.git
cd rejson/
make
after the make command i dont have a file called rejson.so anywhere however make command finished without error
so that's why i cant load module to my redis
i am using ubuntu 20.04
i also have tried to clone from https://github.com/RedisJSON/RedisJSON.git and it didn't work either
Cloning master from each of those repositories produces a librejson.so in the target/release directories. Cloning the 1.0 branch produces rejson.so and the docs in each branch point to the appropriate shared object.
Can you share your output?
Related
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 wrote a Singularity container that works just fine on my computer. However, when a colleague of mine tries to run it, he gets the error output
FATAL: container creation failed: failed to resolve session directory /usr/local/var/singularity/mnt/session: lstat /usr/local/var: no such file or directory
In the past, he could run containers I build. In fact, he used being able to run a container with the same recipe. The change was that the version of Singularity on the machine I use to build it was upgraded.
I entered the error in a search engine, and I only found a single hit, https://forum.image.sc/t/improving-cluster-supercomputer-performance-tesla-v100-volta-16-32gb-gpu/37459/8, in which this is not resolved.
Does anybody know a way to fix this? Or what the source of the problem is? Or a workaround, preferably one that does not require me to downgrade Singularity? (The machine on which I build it is shared between several users, that's why I don't want to do that.)
Okay, this was somewhat trivial to solve, we just had the colleague create the required folder,
mkdir -p /usr/local/var/singularity/mnt/{container,final,overlay,session}
I want to setup apache openwhisk on-premise in my organization. so that we can use it internally within the org. i am not able to find much on the net on this. i tried cloning the code from git and building it in the windows. but it doesn't work. kindly help
Follow these steps to start the platform in a virtual machine in your local environment.
# Clone openwhisk
git clone --depth=1 https://github.com/openwhisk/openwhisk.git
# Change directory to tools/vagrant
cd openwhisk/tools/vagrant
# Run script to create vm and run hello action
./hello
If this works, you should see the following output.
wsk action invoke /whisk.system/utils/echo -p message hello --result
{
"message": "hello"
}
If you encounter problems with these steps, please open an issue in the Github repository for the project.
Deploy OpenWhisk using the ansible playbook in high-availability mode.
I'm trying to tag the git repo of a ruby gem in a Bamboo build. I thought doing something like this in ruby would do the job
`git tag v#{current_version}`
`git push --tags`
But the problem is that the repo does not have the origin. somehow Bamboo is getting rid of the origin
Any clue?
Yes, if you navigate to the job workspace, you will find that Bamboo does not do a straightforward git clone "under the hood", and the the remote is set to an internal file path.
Fortunately, Bamboo does store the original repository URL as ${bamboo.repository.git.repositoryUrl}, so all you need to do is set a remote pointing back at the original and push to there. This is what I've been using with both basic Git repositories and Stash, creating a tag based on the build number.
git tag -f -a ${bamboo.buildNumber} -m "${bamboo.planName} build number ${bamboo.buildNumber} passed automated acceptance testing." ${bamboo.planRepository.revision}
git remote add central ${bamboo.planRepository.repositoryUrl}
git push central ${bamboo.buildNumber}
git ls-remote --exit-code --tags central ${bamboo.buildNumber}
The final line is simply to cause the task to fail if the newly created tag cannot be read back.
EDIT: Do not be tempted to use the variable ${bamboo.repository.git.repositoryUrl}, as this will not necessarily point to the repo checked out in your job.
Also bear in mind that if you're checking out from multiple sources, ${bamboo.planRepository.repositoryUrl} points to the first repo in your "Source Code Checkout" task. The more specific URLs are referenced via:
${bamboo.planRepository.1.repositoryUrl}
${bamboo.planRepository.2.repositoryUrl}
...
and so on.
I know this is an old thread, however, I thought of adding this info.
From Bamboo version 6.7 onwards, it has the Git repository tagging feature Repository Tag.
You can add a repository tagging task to the job and the Bamboo variable as tag name.
You must have Bamboo-Bitbucket integrated via the application link.
It seems that after a checkout by the bamboo agent, the remote repository url for origin is set as file://nothing
[remote "origin"]
url = file://nothing
fetch = +refs/heads/*:refs/remotes/origin/*
That's why we can either update the url using git remote set-url or in my case I just created a new alias so it does not break the existing behavior. There must be a good reason why it is set this way.
[remote "build-origin"]
url = <remote url>
fetch = +refs/heads/*:refs/remotes/build-origin/*
I also noticed that using ${bamboo.planRepository.<position>.repositoryUrl} did not work for me since it was defined in my plan as https. Switching to ssh worked.
I try to clone a GIT repository with EGit using SSH. I can log on to the machine, see the available branches and choose where to put everything locally. Then when I proceed to actually do the cloning, I get an Eclipse "Problem Occured" box stating:
"Cloning from ssh://[my user name]#[my address] has encountered a problem. ssh://[my user name]#[my address]: Password:". The details for the problem only list "ssh://[my user name]#[my address]: Password:" twice.
The only possible reason I can think of, might be that on the remote compute only Git 1.6.0.x is installed - and I don't have the rights to update it.
Can you clone the repository using native git? If you can do that, just clone it using native git and then import the project into eclipse using:
File -> Import -> Projects from Git -> Local
If your eclipse runs on Windows, you will need a linux machine (virtual machine will do) and clone the repo into a NTFS or Fat32 formatted storage. Then you will be able to copy the cloned repo into your git folder on the windows machine.