Logstash not loading config pipeline on startup - logstash

I installed the ELK (version 5.6 elastic / logstash / kibana) stack on a CentOS 7 (using version 5.6) box using the rpm method, and have services enabled to run on startup. I verify it is running after reboot like so:
ps aux | grep logstash
logstash 744 4.6 2.2 3381144 363308 ? SNsl 09:06 0:48 /usr/bin/java -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:+HeapDumpOnOutOfMemoryError -Xmx1g -Xms256m -Xss2048k -Djffi.boot.library.path=/usr/share/logstash/vendor/jruby/lib/jni -Xbootclasspath/a:/usr/share/logstash/vendor/jruby/lib/jruby.jar -classpath : -Djruby.home=/usr/share/logstash/vendor/jruby -Djruby.lib=/usr/share/logstash/vendor/jruby/lib -Djruby.script=jruby -Djruby.shell=/bin/sh org.jruby.Main /usr/share/logstash/lib/bootstrap/environment.rb logstash/runner.rb --path.settings /etc/logstash
I don't see anything in that process command regarding my pipeline configurations. In my settings file, I have path.config : /etc/logstash/conf.d/*.conf.
This is modified from the default path.config : /etc/logstash/conf.d/ which according to the documentation does the exact same thing (and I've tried both).
The 3 files I have are valid, as I can ingest data manually using:
/usr/share/logstash/bin/logstash -f '/etc/logstash/conf.d/{fileA,fileB,fileC}.conf' (or I can run them individually).
I want these ingestion pipelines to start when my server reboots, but I believe I have my configurations set correctly. I even re-ran the system-install script for good measure. Any ideas?

I ended up manually changing the systemd config for logstash by going to /etc/systemd/system/logstash.service and changing:
ExecStart=/usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash"
to:
ExecStart=/usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash" "-f" "/etc/logstash/conf.d/{fileA,fileB,fileC}.conf"
After rebooting, I discovered the process was indeed loading these pipelines.

Related

The Intellij IDEA does not launch after editing the VM options file

In Intellij IDEA 2019 I mistakenly added incorrect lines to the VM option file (Menu | Help | Edit Custom VM Options). After that, the IDEA does not launch. Reinstallation didn't help. When I run IDEA from terminal, it gives the following error:
~/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/193.7288.26/bin$ ./idea.sh
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated
in version 9.0 and will likely be removed in a future release.
Error: Could not find or load main class org.gradle.jvmargs=-Xmx2048M,
-XX:MaxMetaspaceSize=512m Caused by: java.lang.ClassNotFoundException:
org.gradle.jvmargs=-Xmx2048M, -XX:MaxMetaspaceSize=512m
But at the same time, these lines are not in the idea64.vmoptions file:
~/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/193.7288.26/bin$ cat idea64.vmoptions
-Xms128m
-Xmx750m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-XX:CICompilerCount=2
-Dsun.io.useCanonPrefixCache=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Djdk.attach.allowAttachSelf=true
-Dkotlinx.coroutines.debug=off
-Djdk.module.illegalAccess.silent=true
-Dawt.useSystemAAFontSettings=lcd
-Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
-Dsun.tools.attach.tmp.only=true
I don't understand what the error is. Can anyone help? Thanks for any comment/answer!
Delete/edit the custom .vmoptions file.
Usually it's located in the IDE configuration directory.
On Linux look for
~/.config/JetBrains/IntelliJIdea2020.2/idea64.vmoptions (for 2020.2 Ultimate)
~/.IntelliJIdea2019.3/config/idea64.vmoptions (2019.3 Ultimate)
~/.IdeaIC2019.3/config/idea64.vmoptions (2019.3 Community)
Toolbox managed installations may use different location:
~/.local/share/JetBrains/Toolbox/apps/IDEA-C/ch-0/193.7288.26.vmoptions

Spark master and worker seem to run on different JVM version

In standalone mode master process uses /usr/bin/java which resolves to JVM 1.8 and worker process /usr/lib/jvm/java/bin/java which resolves to 1.7. In my Spark application I'm using some APIs introduced in 1.8.
Looking at stack trace one line that comes up is: Caused by: java.lang.NoClassDefFoundError: Could not initialize class SomeClassDefinedByMe which internally creates instance from java.time which I believe is only in JDK 1.8.
How do I force worker to use JVM 1.8?
Update:
For now I renamed /usr/lib/jvm/java/bin/java and created a link that points to /usr/bin/java. This solved the problem but still would like to know why both processes use different binary location and where is this set.
On each Worker node, edit ${SPARK_HOME}/conf/spark-env.sh and define the appropriate $JAVA_HOME e.g.
export JAVA_HOME=/usr/bin/java
That file is sourced by ${SPARK_HOME}/bin/load-spark-env.sh which is invoked by each and every Spark command-line utility:
${SPARK_HOME}/bin/spark-shell via ${SPARK_HOME}/bin/spark-class
${SPARK_HOME}/bin/spark-submit via ${SPARK_HOME}/bin/spark-class
...
${SPARK_HOME}/sbin/start-slave.sh
...
Side note: the Linux alternatives are the standard way to define which JVM is on top of your PATH...
Typical setup with a "fixed" setting, not relying on the priority set by the OpenJDK RPM install:
$ ls -AFl $(which java)
lrwxrwxrwx. 1 root root 22 Feb 15 16:06 /usr/bin/java -> /etc/alternatives/java*
$ alternatives --display java | grep -v slave
java - status is manual.
link currently points to /usr/java/jdk1.8.0_92/jre/bin/java
/usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java - priority 18091
/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java - priority 16000
/usr/java/jdk1.8.0_92/jre/bin/java - priority 18092
Current `best' version is /usr/java/jdk1.8.0_92/jre/bin/java.
...provided that $PATH is defined properly for the Linux account that launches the Spark slaves!

Elasticsearch error to start service

I have problems starting elasticsearch, the command to start is:
cd /etc/init.d && ./elasticsearch start
Out put.
/opt/jdk1.8.0_77 uno
JAVA /opt/jdk1.8.0_77/bin/java
Starting elasticsearch: [ OK ]
but executed status I get: "elasticsearch dead but subsys locked"
I tried deleting "elasticsearch", in /var/lock/subsys but, this file is generated again.
In the log says.
java.lang.RuntimeException: Java version: 1.7.0_40 suffers from critical bug https://bugs.openjdk.java.net/browse/JDK-8024830 which can cause data corruption.
Please upgrade the JVM, see http://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html for current recommendations.
If you absolutely cannot upgrade, please add -XX:-UseSuperWord to the JVM_OPTS environment variable.
Upgrading is preferred, this workaround will result in degraded performance.
But the process is started with java 8,
elasticsearch 26918 0.8 1.0 30526952 724324 ? Sl Jul03 1:29 /opt/jdk1.8.0_77/bin/java -Xms256m -Xmx1g -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -Dfile.encoding=UTF-8 -Delasticsearch -Des.foreground=yes -Des.path.home=/opt/elasticsearch -cp :/opt/elasticsearch/lib/elasticsearch-1.7.0.jar:/opt/elasticsearch/lib/*:/opt/elasticsearch/lib/sigar/* org.elasticsearch.bootstrap.Elasticsearch
Any help would be appreciated.
Verify java selection
alternatives --config java
Make sure java 8 is in use. Elasticsearch requires at least Java 8.
Please try setting up the variables in /etc/elasticsearch/elasticsearch.yml:
path.data: path/to/data
path.work: path/to/work
path.logs: /var/log/elasticsearch
path.conf: /etc/elasticsearch
Note: Give access to user "elasticsearch" for folder that
elasticsearch uses:
chown -R elasticsearch /path/to/data
chown -R elasticsearch /path/to/work

Android studio gradle HeapDumpOnOutOfMemoryError

My problem
I recently install android studio in Ubuntu 14.
But I have problem in gradle build execution.
gradle not completed for any project even hello world project
What I am tried
1.
File Menu - > Invalidate Caches/ Restart..
2.Increase the heap size manually using this answer
3.Android Studio Gradle loading
But no luck for me.
Error details
Tooling API is using target Gradle version: 2.4.
Starting a new Gradle Daemon for this build (subsequent builds will be faster).
Starting daemon process: workingDir = /home/knonex19/.gradle/daemon/2.4, daemonArgs: [/usr/lib/jvm/java-8-oracle/bin/java, -XX:MaxPermSize=256m, -XX:+HeapDumpOnOutOfMemoryError, -Xmx1024m, -Dfile.encoding=UTF-8, -Duser.country=IN, -Duser.language=en, -Duser.variant, -cp, /home/knonex19/.gradle/wrapper/dists/gradle-2.4-all/6r4uqcc6ovnq6ac6s0txzcpc0/gradle-2.4/lib/gradle-launcher-2.4.jar, org.gradle.launcher.daemon.bootstrap.GradleDaemon, 2.4, /home/knonex19/.gradle, /home/knonex19/.gradle/daemon, 10800000, 3a17e311-fb84-4407-a62b-c87d02683ab5, -XX:MaxPermSize=256m, -XX:+HeapDumpOnOutOfMemoryError, -Xmx1024m, -Dfile.encoding=UTF-8, -Duser.country=IN, -Duser.language=en, -Duser.variant]
Starting process 'Gradle build daemon'. Working directory: /home/knonex19/.gradle/daemon/2.4 Command: /usr/lib/jvm/java-8-oracle/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=IN -Duser.language=en -Duser.variant -cp /home/knonex19/.gradle/wrapper/dists/gradle-2.4-all/6r4uqcc6ovnq6ac6s0txzcpc0/gradle-2.4/lib/gradle-launcher-2.4.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 2.4 /home/knonex19/.gradle /home/knonex19/.gradle/daemon 10800000 3a17e311-fb84-4407-a62b-c87d02683ab5 -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=IN -Duser.language=en -Duser.variant
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 0.902 secs.
Connected to daemon DaemonInfo{pid=2796, address=[ec70070e-7a08-4520-a3ae-0c0b751449aa port:38689, addresses:[/0:0:0:0:0:0:0:1%lo, /127.0.0.1]], idle=false, context=DefaultDaemonContext[uid=3a17e311-fb84-4407-a62b-c87d02683ab5,javaHome=/usr/lib/jvm/java-8-oracle,daemonRegistryDir=/home/knonex19/.gradle/daemon,pid=2796,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=IN,-Duser.language=en,-Duser.variant]}. Dispatching request Build{id=9fe736cb-042e-4d0f-a55b-f95626396a77.1, currentDir=/home/knonex19/Desktop/tummyfulltabletpos}.
[ 351800] WARN - ConfigurableExtensionPointUtil - Can't find parent for project.propCompiler (Compiler)
Anybody solve my issue thanks..

shared.loader="${catalina.home}/shared/classes not working on LINUX but working on WINDOWS

Does anyone know the reason why this would work in WINDOWS (tomcat 8.0.9) and not on LINUX (tomcat 6)?
I set catalina.properties (/etc/tomcat6/catalina.properties) file to:
shared.loader="${catalina.home}/shared/classes","${catalina.home}/shared/lib/*.jar"
But it is still not working...
If I run:
ps aux | grep catalina
I get:
tomcat 22199 0.1 14.2 2229892 1133948 ? Sl Sep12 7:41 /etc/alternatives/jre/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms512m -Xmx1280m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -classpath .:/usr/lib64/jvm/java:/usr/lib64/logi-lib:/usr/share/java:/usr/share/tomcat6/lib:/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
On my windows machine all I had to do is set shared.folder in catalina.properties file and make sure I do have classes I am calling in there.
Btw, I don't have admin rights on linux machine
May be you must create the shared/classes and shared/lib folders under /usr/share/tomcat6.
In windows usually this folders are under the tomcat6 folder, but installations in Linux environment are quite different in this point.

Resources