I install apache drill on a cluster with 3 nodes.
When I use the following command to start it,it will not really running.
bin/drillbit.sh start
error
I don't know how to solve it and want you help.
The zookeeper is running without problems.
Then I check the log, and it show the following infos:
Exception in thread "main" org.apache.drill.exec.exception.DrillbitStartupException: Failure while initializing values in Drillbit.
at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:287)
at org.apache.drill.exec.server.Drillbit.start(Drillbit.java:271)
at org.apache.drill.exec.server.Drillbit.main(Drillbit.java:267)
Caused by: org.apache.drill.exec.exception.DrillbitStartupException: Problem in finding the native library of JPAM (Pluggable Authenticator Module API). Make sure to set Drillbit JVM option 'java.library.path' to point to the directory where the native JPAM exists.:no jpam in java.library.path
I check the java.library.path, it is the following:
/home/hadoop/bigdata/hadoop-2.7.2/lib/native/::/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
So, I add the following setting:
declare -x DRILL_JAVA_LIB_PATH="/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib"
However, it not work and turn out the same problem like before.
The declare -x DRILL_JAVA_LIB_PATH snippet you provided will not point drill to the pam library. Please follow all the instructions in the Drill docs here https://drill.apache.org/docs/using-jpam-as-the-pam-authenticator/
Note: you will have to perform those steps on all 3 nodes of your cluster.
Related
I am just finding wazuh and wanted to test it out. I have tried the step by step and the scripted. Cannot get it to work. So I am consolidating my deployment to just 1 VM and am trying to run the quickstart to get going. When I try to install I get the below error. I cannot find anything related to wazuh-indexer 4.3.1-1. Thoughts?
10/05/2022 12:52:37 INFO: Created wazuh-install-files.tar. It contains the Wazuh cluster key, certificates, and passwords necessary for installation.
10/05/2022 12:52:37 INFO: --- Wazuh indexer ---
10/05/2022 12:52:37 INFO: Starting Wazuh indexer installation.
Updating Subscription Management repositories.
EL-8 - Wazuh 75 kB/s | 3.4 kB 00:00
No match for argument: wazuh-indexer-4.3.1-1
Error: Unable to find a match: wazuh-indexer-4.3.1-1
10/05/2022 12:52:48 ERROR: Wazuh indexer installation failed.
10/05/2022 12:52:48 INFO: --- Removing existing Wazuh installation ---
10/05/2022 12:52:48 INFO: Installation cleaned. Check the /var/log/wazuh-install.log file to learn more about the issue.
The root of that error is that the script is trying to download
wazuh-indexer-4.3.1-1 instead of the current wazuh-indexer-4.3.0-1.
It seems that the production script included this bug for a short period of time. Please download the script and install it again.
Sorry for the inconvenience.
You are correct. After waiting a few days, the bug was fixed. But am now hitting a new bug. When trying to run filebeat setup --dashboards. I get an error: Exiting: Kibana API is not available in Kibana version 1.2.0
I have the setting:
compatibility.override_main_response_version: true
on my opensearch.yml but still no avail.
If you are using the wazuh-install script, it is not required to perform any further configuration.
In order to troubleshoot this issue, could you please provide us with the following information:
Architecture: Single host or multi-node
Installation method: Step by step installation
Documentation page you follow to install your environment
OS of your nodes
I recommend you to join Wazuh slack channel (https://wazuh.com/community/) and move this issue there, or into the Wazuh google group in order to be able to correctly monitor this problem
Jenkins pipeline is building Docker images. OpenShift plugin(s) are used for the same.
An example command:
openshift.selector(BUILD_CONFIG_NAME, "${appBcName}").startBuild("--from-dir=${artifactPath}", '--wait','--follow')
While this works smoothly most of the time, whenever this command fails due to some underlying platform issues, almost no information is seen in the Jenkins build job console:
[Pipeline] }
[start-build:buildconfig/amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd] ............................................................
[start-build:buildconfig/amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd] Uploading finished
[start-build:buildconfig/amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd] Error from server (BadRequest): unable to wait for build amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd-857 to run: timed out waiting for the condition
[Pipeline] }
ERROR: Error running start-build on at least one item: [buildconfig/amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd];
{err=, verb=start-build, cmd=oc --server=https://api.scp-west-zone02-z01.net:6443 --certificate-authority=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt --namespace=sb-1166-amld5-car-service-se --token=XXXXX start-build buildconfig/amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd --from-dir=./build/libs --wait --follow -o=name , out=Uploading directory "build/libs" as binary input for the build ...
............................................................
Uploading finished
Error from server (BadRequest): unable to wait for build amld5-car-reporting-spacetime-ubi-openshift-java-runtimejd-857 to run: timed out waiting for the condition
, status=1}
[Pipeline] // catchError
I need more verbosity, detailed error information. I checked the start-build command reference, and I thought --build-loglevel [0-5] might help here. When I used it, I got a warning that since I am using source type as 'Binary' in the BuildConfig, logging isn't supported(seriously???)
NOTE: the selector returned when -F/--follow is supplied to startBuild() will be inoperative for the various selector operations.
Consider removing those options from startBuild and using the logs() command to follow the build output.
[start-build:buildconfig/casc-docs-spacetime-ubi-openshift-java-runtimeadoptopenjdk] WARNING: Specifying --build-loglevel with binary builds is not supported.
[start-build:buildconfig/casc-docs-spacetime-ubi-openshift-java-runtimeadoptopenjdk] WARNING: Specifying environment variables with binary builds is not supported.
[start-build:buildconfig/casc-docs-spacetime-ubi-openshift-java-runtimeadoptopenjdk] Uploading directory "build/libs" as binary input for the build ...
[start-build:buildconfig/casc-docs-spacetime-ubi-openshift-java-runtimeadoptopenjdk] ..
How do I get more logs, info. while executing the start-build command?
I was facing the same problem, I just used something like:
def build = openshift.selector(BUILD_CONFIG_NAME, "${appBcName}").startBuild("--from-dir=${artifactPath}", '--wait','--follow')
build.logs('-f')
And so far it seems to work, I got the logs from my openshift build in my Jenkins pipeline. Now I'll try to get the logs only if build does not Complete, to reduce the overall logs.
(for future searchers like me ^^)
I am currently using CAS 5.2.3 and running our application in a Docker container. It runs fine locally without any issues but when I push the Docker image to the cloud in AWS as a Cloud Formation Stack, it throws the following error
2019-01-28 19:13:31,339 WARN [org.apereo.cas.services.ServiceRegistryConfigWatcher] - <Directory key is no longer valid. Quitting watcher service>
Exception in thread "org.apereo.cas.services.JsonServiceRegistryDao" java.nio.file.ClosedWatchServiceException at sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80)
at sun.nio.fs.AbstractWatchService.checkKey(AbstractWatchService.java:92)
at sun.nio.fs.AbstractWatchService.take(AbstractWatchService.java:119)
at org.apereo.cas.services.ServiceRegistryConfigWatcher.run(ServiceRegistryConfigWatcher.java:72)at java.lang.Thread.run(Thread.java:748)
I am not sure what is causing this. Please let me know if you need any further details.
I search online and someone else also have your problem
Ref: https://groups.google.com/a/apereo.org/forum/#!topic/cas-user/L0XUII6FazI
And judging from they response, the problem was a right issue with Access Right. Maybe this is also your problem?
I am trying to deploy a Play Framework 2.3 application to OpenShift.
I am following this example: https://github.com/JamesSullivan/play2-openshift-quickstart
Building and deploying the application is working (by that I mean the push to the git repository is working and the build is completing successfully), but during startup I see this error in play.log:
AbstractConnectionHook -
Failed to obtain initial connection Sleeping for 0ms and trying again.
Attempts left: 0. Exception: null.
Message:No suitable driver found for jdbc:${OPENSHIFT_POSTGRESQL_DB_URL}
Oops, cannot start the server.
Configuration error: Configuration error[Cannot connect to database [default]]
at play.api.Configuration$.play$api$Configuration$$configError(Configuration.scala:94)
at play.api.Configuration.reportError(Configuration.scala:743)
at play.api.db.BoneCPPlugin$$anonfun$onStart$1.apply(DB.scala:247)
at play.api.db.BoneCPPlugin$$anonfun$onStart$1.apply(DB.scala:238)
at scala.collection.immutable.List.map(List.scala:272)
at play.api.db.BoneCPPlugin.onStart(DB.scala:238)
at play.api.Play$$anonfun$start$1$$anonfun$apply$mcV$sp$1.apply(Play.scala:91)
at play.api.Play$$anonfun$start$1$$anonfun$apply$mcV$sp$1.apply(Play.scala:91)
at scala.collection.immutable.List.foreach(List.scala:381)
at play.api.Play$$anonfun$start$1.apply$mcV$sp(Play.scala:91)
at play.api.Play$$anonfun$start$1.apply(Play.scala:91)
at play.api.Play$$anonfun$start$1.apply(Play.scala:91)
at play.utils.Threads$.withContextClassLoader(Threads.scala:21)
at play.api.Play$.start(Play.scala:90)
at play.core.StaticApplication.<init>(ApplicationProvider.scala:55)
at play.core.server.NettyServer$.createServer(NettyServer.scala:244)
at play.core.server.NettyServer$$anonfun$main$3.apply(NettyServer.scala:280)
at play.core.server.NettyServer$$anonfun$main$3.apply(NettyServer.scala:275)
at scala.Option.map(Option.scala:145)
at play.core.server.NettyServer$.main(NettyServer.scala:275)
at play.core.server.NettyServer.main(NettyServer.scala)
Caused by: java.sql.SQLException: No suitable driver found for jdbc:${OPENSHIFT_POSTGRESQL_DB_URL}
at java.sql.DriverManager.getConnection(DriverManager.java:596)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at com.jolbox.bonecp.BoneCP.obtainRawInternalConnection(BoneCP.java:363)
at com.jolbox.bonecp.BoneCP.<init>(BoneCP.java:416)
at com.jolbox.bonecp.BoneCPDataSource.getConnection(BoneCPDataSource.java:120)
at play.api.db.BoneCPPlugin$$anonfun$onStart$1.apply(DB.scala:240)
... 18 more
So it looks like the ${OPENSHIFT_POSTGRESQL_DB_URL} environment variable token-substitution is not working.
If I log in to my application, I see this via env (obviously I replaced the username, password, IP and port for the purposes of posting here):
OPENSHIFT_POSTGRESQL_DB_URL=postgresql://xxxx:yyyy#ip:port
I have also tried using the other environment variables, like OPENSHIFT_POSTGRESQL_DB_HOST but those too do not get substituted.
The relevant part of my openshift.conf looks like this:
db.default.driver=org.postgresql.Driver
db.default.url="jdbc:${OPENSHIFT_POSTGRESQL_DB_URL}"
db.default.user=myappuser
db.default.password=myapppassword
From the linked quickstart project, the following command is used to start the Play server (again, I replaced server-ip for the purposes of this post):
/app-root/runtime/repo/target/universal/stage/bin/myapp
"-DapplyEvolutions.default=true"
-Dhttp.port=8080 -Dhttp.address=server-ip
-Dconfig.resource=openshift.conf
You can see the openshift.conf file being referenced.
I tried a lot of things, eventually I found something that worked:
db.default.driver=org.postgresql.Driver
db.default.url="jdbc:postgresql://"${OPENSHIFT_POSTGRESQL_DB_HOST}":"${OPENSHIFT_POSTGRESQL_DB_PORT}/mydb
db.default.user=(((db-user)))
db.default.password=(((dp-password)))
The upshot is, it seems, you need to watch out very carefully for correct usage of the quotation characters.
It looks "wrong" (at first glance) since the last quotation character closes the string prior to the OPENSHIFT_POSTGRESQL_DB_PORT variable.
When I was trying to replace the hsqldb with the mysql-5.X I get the following error with quartz error failed to initialize:-
Pentaho Initialization Exception
The following errors were detected
One or more system listeners failed. These are set in the systemListeners.xml.
PentahoSystem.ERROR_0014 - Error while trying to execute startup sequence for org.pentaho.platform.scheduler.QuartzSystemListener
Please see the server console for more details on each error detected.
Did you run the quartz scripts which setup the quartz db? they are provided in the solution repository.
Otherwise pastebin the full log, it's impossible to tell without more info. suspect somewhere you'll either have a authentication issue, or no mysql driver in your classpath.
For a clear guide on how to do this, follow here:
http://www.prashantraju.com/2010/12/pentaho-3-7-with-mysql-postgresql-oracle-and-sql-server/
I also received the error message
PentahoSystem.ERROR_0014 – Error while trying to execute startup sequence for org.pentaho.platform.scheduler.QuartzSystemListener
when trying to bring up the service. I found this solution after searching a few different threads:
Remove commented out portion of these properties (or copy and paste from here, and modify as necessary) in quartz.properties (located in pentaho-solutions/system/quartz):
org.quartz.dataSource.quartz.driver = com.mysql.jdbc.Driver
org.quartz.dataSource.quartz.URL = jdbc:mysql://localhost:3306/quartz
org.quartz.dataSource.quartz.user = pentaho_user
org.quartz.dataSource.quartz.password = password
org.quartz.dataSource.quartz.maxConnections = 5
org.quartz.dataSource.quartz.validationQuery= select 1
Also comment out the JNDI Url:
#org.quartz.dataSource.myDS.jndiURL = Quartz