Develop Reference

Could not create service of type FileHasher using GradleUserHomeServices.createCachingFileHasher()

When I try to run 2 gradle projects simultaneously, it throws me the following error:
Could not create service of type FileHasher using GradleUserHomeServices.createCachingFileHasher().
Timeout waiting to lock file hash cache(/Users/username/.gradle/caches/6.4/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 40300
Our PID: 44136
Owner Operation:
Our operation:
Lock file: /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock
I have read that the best solution is to kill practically all the java processes with the command "killall -9 java" or some derivative that kills the process that prevents the new application from starting, and yes, when I finish an application I can start any of the others , but the thing is that I actually need to run 3 applications that communicate with each other on my local machine, but when I run the first one, the other 2 give me that error.

I'll answer my own question in case someone finds it useful:
The solution is to specify a different gradle-user-home for each job. Specifically, setting it to the current working directory. (i.e. project directory) and you can do it whit the following command:
./gradlew -g $PWD <build (or bootRun or etc the command you need)>

Exception:
Could not create service of type FileHasher using GradleUserHomeServices.createCachingFileHasher().
Timeout waiting to lock file hash cache(/Users/username/.gradle/caches/6.4/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 40300
Our PID: 44136
Owner Operation:
Our operation:
Lock file: /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock
Removing lock file worked for me
rm /Users/epereda/.gradle/caches/6.4/fileHashes/fileHashes.lock

Use docker-machine create from java

I have an application that (I want to) uses Java to start and stop Docker containers. It seems that the way to do this is using docker-machine create, which works fine when I test from the command line.
However, when running using Commons-Exec from Java I get the error:
(aa4567c1-058f-46ae-9e97-56fb8b45211c) Creating SSH key...
Error creating machine: Error in driver during machine creation: /usr/local/bin/VBoxManage modifyvm aa4567c1-058f-46ae-9e97-56fb8b45211c --firmware bios --bioslogofadein off --bioslogofadeout off --bioslogodisplaytime 0 --biosbootmenu disabled --ostype Linux26_64 --cpus 1 --memory 1024 --acpi on --ioapic on --rtcuseutc on --natdnshostresolver1 off --natdnsproxy1 on --cpuhotplug off --pae on --hpet on --hwvirtex on --nestedpaging on --largepages on --vtxvpid on --accelerate3d off --boot1 dvd failed:
VBoxManage: error: Could not find a registered machine with UUID {aa4567c1-058f-46ae-9e97-56fb8b45211c}
VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBoxWrap, interface IVirtualBox, callee nsISupports
VBoxManage: error: Context: "FindMachine(Bstr(a->argv[0]).raw(), machine.asOutParam())" at line 500 of file VBoxManageModifyVM.cpp
I have set my VBOX_USER_HOME variable in an initializationScript that I'm using to start the machine:
export WORKERID=$1
export VBOX_USER_HOME=/Users/me/Library/VirtualBox
# create the machine
docker-machine create $WORKERID && \ # create the worker using docker-machine
eval $(docker-machine env $WORKERID) && \ # load the env of the newly created machine
docker run -d myimage
And I'm executing this from Java via the Commons Exec CommandLine class:
CommandLine cmdline = new CommandLine("/bin/sh");
cmdline.addArgument(initializeWorkerScript.getAbsolutePath());
cmdline.addArgument("test");
Executor executor = new DefaultExecutor();
If there is another library that can interface with docker-machine from Java I'm happy to use that, or to change out Commons Exec if that's the issue (though I don't understand why). The basic requirement is that I have some way to get docker-machine to create a machine using Java and then later to be able to use docker-machine to stop that machine.

As it turns out the example that I posted should work, the issue that I was having is that I was provisioning machines with a UUID name. That name contained dash (-) characters which apparently break VBoxManage. This might be because of some kind of path problem but I'm just speculating. When I changed my UUID to have dot (.) instead of dash it loaded and started the machine just fine.
I'm happy to remove this post if the moderators want, but will leave it up here in case people are looking for solutions to problems with docker-machine create naming issues.

Ctrl-M Filewatcher job invoking a shell script fails

Facing the below error when running the filewatcher job. File that is being watched is already in place.
ctmfw /amex/RSM_1099CTEST.txt CREATE 0 1800 10 3 0 N 0001 2359 NO_MIN_AGE NO_MAX_AGE
/opt/bmc/controlm/cmagentd/ctm/runtime/CMD.0000ctkt_002: line 2:
ctmfw: command not found
Can someone help me identify the cause of this issue.
Thanks in Advance!

The ctmfw command is provided by Control-M/Agent component. You must validate that you are running that Job on a server where a Control-M Agent is installed. In addition, it must be executed with the operating system user under which the agent was installed or, with a user who has execution privileges over the ctmfw utility.

websphere - CWWKE0054E error unable to open file

i am trying run the websphere liberty profile server from the command line. I am following the steps told here : https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/
I have created the server with the name server1.
But when the extraction completes and I try to start the server using the command : server start server1
the server throws an error : CWWKE0054E: Unable to open file C:\wlp\wlp\usr\servers\server1\logs\C:\Users\Furquan\AppData\Local\Temp\\ihp_custom_batches.log.. Now I know this cant be a valid path, but I dont know where and how to change it. Please help !!

This error is related to the LOG_FILE environment variable that you have defined in your environment by some other program. To solve that, you have the following opions:
Remove LOG_FILE env variable, if it is no longer needed by your system
If you cant do that, override it via server.env file, that you can create in the wlp\usr\servers\serverName directory with the following content:
LOG_FILE=console.log
As last resort (this is not recommended, will make your installation NOT SUPPORTED and in certain installations might get overwritten by updates) - modify the server.bat command line script - in the script find the following section:
if not defined LOG_FILE (
set X_LOG_FILE=console.log
) else (
set X_LOG_FILE=!LOG_FILE!
)
And after the line set X_LOG_FILE=!LOG_FILE! just add another line that will override it with the default like this set X_LOG_FILE=console.log
In general, I'd recommend second solution (with the server.env file), as it is the most portable and will work in any environment.

I have the similar problem for IBM Support Assistant V5. After I deleted %LOG_FILE% from Environment Variables, it worked.

Youtrack 6 reboot fails on Fedora and Java Service Wrapper

I have followed http://confluence.jetbrains.com/display/YTD6/Linux.+YouTrack+JAR+as+a+Service on Fedora server. Starting Youtrack 6 as "youtrack" user by
/etc/init.d/youtrack start
command starts properly. I have added youtrack service wrapper on boot by
/sbin/chkconfig --add youtrack
command. But after server reboot Youtrack application is not running.
journalctl -xn
command gives me only this hint
systemd[4000]: Failed at step EXEC spawning /etc/rc.d/init.d/youtrack: Exec format error
I have fixed my permissions like in this thread ''
Starting YouTrack as a service fails without error message''
But error still occurs. I have pasted default template from the tutorial '/etc/rc.d/init.d/youtrack' with only one change:
#export JAVA_HOME=/usr/java/jdk1.6.0_21
export JAVA_HOME=/usr/java/latest
/usr/java/latest points to Oracle JDK 8.

youtrack_initd.template
from youtrack tutorial is missing
#!/bin/sh
on the top of the file. After adding this line "Exec format error" does not occur anymore.