Hello,
We are trying to install DB Connect 3.1.4 on a new Splunk instance (Splunk Entreprise 7.2.6 on Linux RedHat server).
We previously installed java 1.8 (jre1.8.0_211-amd64), the path to the jre is /usr/java/jre1.8.0_211-amd64/ the directory is owned by the user that launches the Splunk service.
It's not the first time we are installing DB Connect, we already did it twice on Splunk 7.2.1 and followed the same configurations.
So after installing the app DB Connect we get the error "Cannot communicate with task server, please check your settings".
index=_internal sourcetype=dbx*
, only logs like 2019-06-11T17:21:04+0200 [INFO] [settings.py], line 121: update java path file [/splunk/etc/apps/splunk_app_db_connect/linux_x86_64/bin/customized.java.path]
Telling us that we are editing the java path.We tried restarting Splunk or installing a whole JDK instead of JRE, we don't know what to do anymore.
Does anyone have any ideas?
Thank you for your help!
Simple:-
1) Open:- vim /etc/profile
export JAVA_HOME="/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/"
export PATH=$JAVA_HOME/bin:$PATH
save the above two lines
2) source /etc/profile
The above command will update in OS or logout and login to ssh.
3) restart splunkd service
4) Now go to UI, splunk_db_connect, configuration, general,
JRE Installation Path(JAVA_HOME) -> /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre
save, it will work
I have also installed jdk(18) but there is no folder called jre in it. all it has is /bin, conf, include, jmods, legal and lib. plz advise!
Update
We looked into the Monitoring Console to perform a healtcheck of the app DB Connect. Basically we get some expected errors for inputs/outputs/lookups/identities/connections/drivers because DBX Server is not available, please make sure it is started and listening on 9998 port or consult documentation for details.
.
And then we get what seems to be the main problem at the step Java Server configuration: The bootstrap conditions of the Java Server fail. The modular input to start the Java Server failed to be registered to Splunk
Also it seems the JVM installation is correct according to the healthcheck (correct version and java path is correctly set by DB Connect commands and server).
I know this is an old one, but my searches brought me here and it might bring someone else here.
After going through installing new java versions and all the JAVA HOME settings, I used my EDR tool and noticed this file was being called:
/opt/splunk/etc/apps/splunk_app_db_connect/linux_x86_64/bin/customized.java.path
It had reference to the older java versions and not the new one. Updated the path in there.
So for anyone who finds this and has problems starting up the taskserver after updating Java. search for the "customized.java.path" file in the dbConnect app folders.
I believe it's the https://docs.splunk.com/Documentation/DBX/3.14.1/DeployDBX/Prerequisites#Configure_Java_Runtime_Envi... step. (True, the docs could say how to do it without the GUI; it might be worth posting a docs feedback - bottom of the webpage)
Hi @performancemonitoring,
Check this out :
https://answers.splunk.com/answers/702333/dbconnect-cannot-communicate-with-task-server.html
Set JDK path not JRE.
Cheers,
David
So we installed a JDK, set the $JAVA_HOME and the JRE Installation Path in DB Connect to "/usr/java/jdk1.8.0_191-amd64", saved the settings (here we get the usual error "Failed to restart task server.") and then restarted Splunk as mentioned in the thread but it still doesn't work after that.
From this error : "DBX Server is not available, please make sure it is started and listening on 9998 port" it seems that firewalld might be blocking your port... try to allow it using firewall-cmd
.
Also have a look here, this could help :
https://answers.splunk.com/answers/518247/how-to-resolve-unable-to-initialize-modular-input.html
Hi performancemonitoring,
Did you set $JAVA_HOME?
We have set JAVA_HOME with "/usr/java/jre1.8.0_211-amd64", restarted Splunk and tried to communicate with the task server but it didn't work.
Also it seems we didn't set $JAVA_HOME for our 2 previous instances and yet it worked for them, so this is a bit confusing.