I have Jenkins 2.164.3 on a CentOS 7 server.
I have a Windows Server 2003 slave with Java version 1.8.0.
I have 3 x linux slaves working successfully.
The windows service on the slave is installed and running.
The windows slave is setup with the following with Launch Method "Let jenkins control this Windows salve as a Windows server"
This Jenkins server is a new server that replaced an older jenkins server (debian wheezy from turnkey linux ~3 years ago). This windows slave used to connect to that old server. To remove the connection on this slave to the old server, I did the following:
1. sc delete
2. deleted the files in folder c:\jenkins
3. rebooted server
4. from new jenkins server, launched slave which copied files to c:\jenkins folder and installed service.
On my new jenkins server, I setup the windows slave and when I connect, the log has the following:
[2019-05-27 12:24:07] [windows-slaves] Connecting to 192.168.1.152
Checking if Java exists
java -version returned 1.8.0.
[2019-05-27 12:24:16] [windows-slaves] Copying jenkins-slave.xml
[2019-05-27 12:24:16] [windows-slaves] Copying slave.jar
[2019-05-27 12:24:16] [windows-slaves] Starting the service
[2019-05-27 12:24:16] [windows-slaves] Waiting for the service to become ready
ERROR: [2019-05-27 12:24:52] [windows-slaves] The service did not respond. Perhaps it failed to launch?
[2019-05-27 12:36:00] [windows-slaves] Connecting to 192.168.1.152
Checking if Java exists
java -version returned 1.8.0.
[2019-05-27 12:36:08] [windows-slaves] Copying jenkins-slave.xml
[2019-05-27 12:36:08] [windows-slaves] Copying slave.jar
[2019-05-27 12:36:08] [windows-slaves] Starting the service
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
org.jinterop.dcom.common.JIException: Service Already Running
at org.jvnet.hudson.wmi.Win32Service$Implementation.start(Win32Service.java:149)
Caused: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.kohsuke.jinterop.JInteropInvocationHandler.invoke(JInteropInvocationHandler.java:140)
Caused: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy90.start(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:342)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:294)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
The windows slave is Windows Server 2003, the service is installed and running.
In the log file C:\Jenkins\jenkins-slave.wrapper.log, it has the following:
2019-05-27 12:19:32,644 INFO - Starting ServiceWrapper in the service mode
2019-05-27 12:19:32,659 INFO - Starting javaw.exe -Xrs -jar "C:\Jenkins\slave.jar" -tcp "C:\Jenkins\port.txt"
2019-05-27 12:19:32,675 INFO - Extension loaded: killOnStartup
2019-05-27 12:19:32,675 DEBUG - Checking the potentially runaway process with PID=1408
2019-05-27 12:19:32,675 DEBUG - No runaway process with PID=1408. The process has been already stopped.
2019-05-27 12:19:32,675 INFO - Starting javaw.exe -Xrs -jar "C:\Jenkins\slave.jar" -tcp "C:\Jenkins\port.txt"
2019-05-27 12:19:32,691 INFO - Started process 4084
2019-05-27 12:19:32,691 DEBUG - Forwarding logs of the process System.Diagnostics.Process (javaw) to winsw.SizeBasedRollingLogAppender
2019-05-27 12:19:32,691 INFO - Recording PID of the started process:4084. PID file destination is C:\Jenkins\jenkins_agent.pid
2019-05-27 12:23:56,529 INFO - Stopping jenkinsslave-C__Jenkins
2019-05-27 12:23:56,529 DEBUG - ProcessKill 4084
2019-05-27 12:23:56,561 INFO - Stopping process 4084
2019-05-27 12:23:56,561 INFO - Send SIGINT 4084
2019-05-27 12:23:56,561 WARN - SIGINT to 4084 failed - Killing as fallback
2019-05-27 12:23:56,561 INFO - Finished jenkinsslave-C__Jenkins
2019-05-27 12:23:56,561 DEBUG - Completed. Exit code is 0
2019-05-27 12:24:16,374 INFO - Starting ServiceWrapper in the service mode
2019-05-27 12:24:16,390 INFO - Starting javaw.exe -Xrs -jar "C:\Jenkins\slave.jar" -tcp "C:\Jenkins\port.txt"
2019-05-27 12:24:16,405 INFO - Extension loaded: killOnStartup
2019-05-27 12:24:16,405 DEBUG - Checking the potentially runaway process with PID=4084
2019-05-27 12:24:16,405 DEBUG - No runaway process with PID=4084. The process has been already stopped.
2019-05-27 12:24:16,405 INFO - Starting javaw.exe -Xrs -jar "C:\Jenkins\slave.jar" -tcp "C:\Jenkins\port.txt"
2019-05-27 12:24:16,421 INFO - Started process 364
2019-05-27 12:24:16,421 DEBUG - Forwarding logs of the process System.Diagnostics.Process (javaw) to winsw.SizeBasedRollingLogAppender
2019-05-27 12:24:16,421 INFO - Recording PID of the started process:364. PID file destination is C:\Jenkins\jenkins_agent.pid
The error on the jenkins server shows the service is not running. On the windows slave machine, the service is running. What is the problem and how do I fix?
Thanks.
Very old question, but if you end up here because you are getting this error, find the jenkins_agent.pid file and delete it. It should be in the same folder the rest of your jenkins slave files. The service should start again normally after that.
I know this question is old and you've long moved on but maybe this will help someone. I ran into a similar problem with a Windows slave, specifically I was seeing it go through a cycle of restarts much like you were:
2019-05-27 12:24:16,405 DEBUG - Checking the potentially runaway process with PID=4084
2019-05-27 12:24:16,405 DEBUG - No runaway process with PID=4084. The process has been already stopped.
2019-05-27 12:24:16,405 INFO - Starting javaw.exe -Xrs -jar "C:\Jenkins\slave.jar" -tcp "C:\Jenkins\port.txt"
2019-05-27 12:24:16,421 INFO - Started process 364
To solve the problem I checked the following:
See if the Windows service is running, cycle it
In addition to checking the C:\<path to jenkins>\jenkins-slave.wrapper.log also have a look at C:\<path to jenkins>\jenkins-slave.err.log
The err log is where I found my problem, I had an issue with a cert unable to find valid certificate
Edit the C:\<path to jenkins>\jenkins-slave.xml file and fix whatever startup parameter is causing you a problem. Make sure to check the java path and version.
In my certificate error case, I needed to add a -noCertificateCheck to my arguments so I could move on
Another potential downfall maybe that the executable setting in the jenkins-slave.xml config file no longer points to a valid java.exe.
This may happen after a Java update
Related
I am trying to setup Sonarqube in my Macbook but I am getting following error when I try to start it with sh sonar.sh console
sudo sh sonar.sh console
Password:
/usr/bin/java
Running SonarQube...
Removed stale pid file: ./SonarQube.pid
INFO app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /Applications/sonarqube/temp
INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on [HTTP: 127.0.0.1:9001, TCP: 127.0.0.1:60506]
INFO app[][o.s.a.ProcessLauncherImpl] Launch process[ELASTICSEARCH] from [/Applications/sonarqube/elasticsearch]: /Applications/sonarqube/elasticsearch/bin/elasticsearch
INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release
at java.base/java.lang.System.setSecurityManager(System.java:416)
at org.elasticsearch.bootstrap.Security.setSecurityManager(Security.java:99)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:70)
2022.08.24 16:24:52 WARN app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [ElasticSearch]: 1
2022.08.24 16:24:52 INFO app[][o.s.a.SchedulerImpl] Process[ElasticSearch] is stopped
2022.08.24 16:24:52 INFO app[][o.s.a.SchedulerImpl] SonarQube is stopped
After some research on internet I have installed Java 11 but it is not helping me.
I have a ktor app. I works fine when I run it in development mode. I package it in a docker image by copying over what the gradle application plugin provided. That also works fine on my local machine 8 cores. But now the strange part. When I do exactly the same thing on a rented V-Server also running Ubuntu-20.04 like my local system, ktor is incredible slow.
docker-compose logs server:
server | 2021-08-24 08:00:23.337 [main] INFO ktor.application - Autoreload is disabled because the development mode is off.
server | 2021-08-24 08:25:35.048 [main] INFO ktor.application - Autoreload is disabled because the development mode is off.
server | 2021-08-24 09:18:48.246 [main] INFO c.e.e.s.TemplateStore - Starting to parse Sentences
server | 2021-08-24 09:18:48.345 [main] INFO c.e.e.s.TemplateStore - Finished parsing sentences
server | 2021-08-24 09:18:48.346 [main] INFO ktor.application - Responding at http://0.0.0.0:8080
server | 2021-08-24 09:18:48.347 [main] INFO ktor.application - Application started in 3193.32 seconds.
Application started in 3193.32 seconds
The source code can be found here https://github.com/1-alex98/whatisthat . It has a docker-compose.yml defining the whole docker container being started.
Local system 32 gb ram + 8 cores . V-Server 4 gb Ram + 2 cores (htop shows pleinty of resources are free).
I am looking for ideas on what in the world could cause this behavior. Or ways to debug it.
Update:
Seems to read a file forever:
"main" #1 prio=5 os_prio=0 cpu=652.14ms elapsed=173.92s tid=0x00007f01d4016000 nid=0xe runnable [0x00007f01dace6000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(java.base#11.0.12/Native Method)
at java.io.FileInputStream.read(java.base#11.0.12/FileInputStream.java:279)
at java.io.FilterInputStream.read(java.base#11.0.12/FilterInputStream.java:133)
at sun.security.provider.NativePRNG$RandomIO.readFully(java.base#11.0.12/NativePRNG.java:424)
at sun.security.provider.NativePRNG$RandomIO.ensureBufferValid(java.base#11.0.12/NativePRNG.java:526)
at sun.security.provider.NativePRNG$RandomIO.implNextBytes(java.base#11.0.12/NativePRNG.java:545)
- locked <0x00000000c7571158> (a java.lang.Object)
at sun.security.provider.NativePRNG$Blocking.engineNextBytes(java.base#11.0.12/NativePRNG.java:268)
at java.security.SecureRandom.nextBytes(java.base#11.0.12/SecureRandom.java:751)
at kotlin.random.AbstractPlatformRandom.nextBytes(PlatformRandom.kt:47)
at kotlin.random.Random.nextBytes(Random.kt:260)
at com.example.routes.websocket.WebsocketRoutingKt.<clinit>(WebsocketRouting.kt:40)
at com.example.plugins.RoutingKt$routing$1.invoke(Routing.kt:13)
at com.example.plugins.RoutingKt$routing$1.invoke(Routing.kt:11)
at io.ktor.routing.Routing$Feature.install(Routing.kt:106)
at io.ktor.routing.Routing$Feature.install(Routing.kt:88)
at io.ktor.application.ApplicationFeatureKt.install(ApplicationFeature.kt:68)
at io.ktor.routing.RoutingKt.routing(Routing.kt:129)
at com.example.plugins.RoutingKt.routing(Routing.kt:11)
at com.example.ApplicationKt$main$1.invoke(Application.kt:18)
at com.example.ApplicationKt$main$1.invoke(Application.kt:14)
at io.ktor.server.engine.internal.CallableUtilsKt.executeModuleFunction(CallableUtils.kt:50)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$launchModuleByName$1.invoke(ApplicationEngineEnvironmentReloading.kt:317)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$launchModuleByName$1.invoke(ApplicationEngineEnvironmentReloading.kt:316)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.avoidingDoubleStartupFor(ApplicationEngineEnvironmentReloading.kt:341)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.launchModuleByName(ApplicationEngineEnvironmentReloading.kt:316)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.access$launchModuleByName(ApplicationEngineEnvironmentReloading.kt:30)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$instantiateAndConfigureApplication$1.invoke(ApplicationEngineEnvironmentReloading.kt:304)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading$instantiateAndConfigureApplication$1.invoke(ApplicationEngineEnvironmentReloading.kt:295)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.avoidingDoubleStartup(ApplicationEngineEnvironmentReloading.kt:323)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.instantiateAndConfigureApplication(ApplicationEngineEnvironmentReloading.kt:295)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.createApplication(ApplicationEngineEnvironmentReloading.kt:136)
at io.ktor.server.engine.ApplicationEngineEnvironmentReloading.start(ApplicationEngineEnvironmentReloading.kt:268)
at io.ktor.server.netty.NettyApplicationEngine.start(NettyApplicationEngine.kt:174)
at com.example.ApplicationKt.main(Application.kt:21)
at com.example.ApplicationKt.main(Application.kt)
It is a fresh rented server but I guess something is wrong with it
docker-compose being slow and my program not starting seemed to be due to insufficient(not good enough) input to /dev/urandom. Installing https://github.com/smuellerDD/jitterentropy-rngd resolved the problem.
I have a brand new sonarqube installation (6.7.1.35068) which is being invoked from a brand-new jenkins server (2.102) using the maven goal. Both are running as services on ec2-linux which is fully patched.
At first it worked.
Then, it sonar began reporting:
java.lang.IllegalArgumentException: Plugin [smells] does not exist
and refusing to run the background analysis, although the jenkins build reports success.
I can run the jenkins job twice in a row and get a success and a failure without changing anything in the servers or the code. And then three failures in a row, then four successes in a row.
The plugin does indeed exist, and the sonar server show it is loaded in its configuration reporting.
I have looked at file permissions on the machine, and everything seems to be owned by the right user with the right permissions.
Has anyone seen this behavior? Any ideas about what other troubleshooting I could do?
Many thanks for any help.
EDIT: Here is the content of sonar.log at startup.
--> Wrapper Started as Daemon
Launching a JVM...
Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
2018.01.22 13:48:02 INFO app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonar/temp
2018.01.22 13:48:02 INFO app[][o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2018.01.22 13:48:02 INFO app[][o.s.a.p.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonar/elasticsearch]: /opt/sonar/elasticsearch/bin/elasticsearch -Epath.conf=/opt/sonar/temp/conf/es
2018.01.22 13:48:03 INFO app[][o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
2018.01.22 13:48:03 INFO app[][o.e.p.PluginsService] no modules loaded
2018.01.22 13:48:03 INFO app[][o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
2018.01.22 13:48:12 INFO app[][o.s.a.SchedulerImpl] Process[es] is up
2018.01.22 13:48:12 INFO app[][o.s.a.p.ProcessLauncherImpl] Launch process[[key='web', ipcIndex=2, logFilenamePrefix=web]] from [/opt/sonar]: /usr/java/jdk1.8.0_121/jre/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonar/temp -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -cp ./lib/common/*:./lib/server/*:/opt/sonar/lib/jdbc/postgresql/postgresql-42.1.4.jar org.sonar.server.app.WebServer /opt/sonar/temp/sq-process7588018711976818336properties
2018.01.22 13:48:28 INFO app[][o.s.a.SchedulerImpl] Process[web] is up
2018.01.22 13:48:28 INFO app[][o.s.a.p.ProcessLauncherImpl] Launch process[[key='ce', ipcIndex=3, logFilenamePrefix=ce]] from [/opt/sonar]: /usr/java/jdk1.8.0_121/jre/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonar/temp -Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError -cp ./lib/common/*:./lib/server/*:./lib/ce/*:/opt/sonar/lib/jdbc/postgresql/postgresql-42.1.4.jar org.sonar.ce.app.CeServer /opt/sonar/temp/sq-process7608302589622094268properties
2018.01.22 13:48:37 INFO app[][o.s.a.SchedulerImpl] Process[ce] is up
2018.01.22 13:48:37 INFO app[][o.s.a.SchedulerImpl] SonarQube is up
And that "no modules loaded" from the plugins service doesn't look so good. In my defense, I was looking at the sonarqube_system_info.json and it reports:
"Plugins": {
"groovy": "1.5 [Groovy]",
"java": "5.0.1.12818 [SonarJava]",
"smells": "4.0.0 [Code Smells]",
"web": "2.5.0.476 [Web]",
"xml": "1.4.3.1027 [SonarXML]",
"clover": "3.1 [Clover]",
"scmmercurial": "1.1.1 [Mercurial]",
"Sonargraph": "3.5 [Sonargraph]",
"aemrules": "0.9 [AEM Rules for SonarQube]",
"checkstyle": "3.7 [Checkstyle]",
"javascript": "4.0.0.5862 [SonarJS]",
"status": "3.0.1 [SVG Badges]"
},
This issue is probably coming from a wrong usage of SonarQube, most probably by using multiple server on the same database.
See more details about how to detect this in thread : https://groups.google.com/forum/#!msg/sonarqube/IPjmDeGDUFc/dHMfJooXAQAJ
I am trying to start Apache nifi version 1.2.0 on window 8 machine. It used to start properly. After I restarted the system the nifi is not starting at all. I had check status Its keep getting "Apacha Nifi not running".
Below are logs from nifi.bootstrap.log file:-
2017-07-05 15:41:57,105 WARN [NiFi Bootstrap Command Listener]
org.apache.nifi.bootstrap.RunNiFi Failed to set permissions so that only the
owner can read pid file E:\softwares\nifi-1.2.0\bin\..\run\nifi.pid; this
may allows others to have access to the key needed to communicate with NiFi.
Permissions should be changed so that only the owner can read this file
2017-07-05 15:41:57,142 WARN [NiFi Bootstrap Command Listener]
org.apache.nifi.bootstrap.RunNiFi Failed to set permissions so that only the
owner can read status file E:\softwares\nifi-1.2.0\bin\..\run\nifi.status;
this may allows others to have access to the key needed to communicate with
NiFi. Permissions should be changed so that only the owner can read this
file
2017-07-05 15:41:57,168 INFO [NiFi Bootstrap Command Listener]
org.apache.nifi.bootstrap.RunNiFi Apache NiFi now running and listening for
Bootstrap requests on port 50765
2017-07-05 15:43:12,077 ERROR [NiFi logging handler] org.apache.nifi.StdErr
Failed to start web server: Unable to start Flow Controller.
2017-07-05 15:43:12,078 ERROR [NiFi logging handler] org.apache.nifi.StdErr
Shutting down...
2017-07-05 15:43:14,501 INFO [main] org.apache.nifi.bootstrap.RunNiFi NiFi
never started. Will not restart NiFi
Stack trace from nifi.app.log: -
2017-07-05 15:43:12,077 WARN [main] org.apache.nifi.web.server.JettyServer Failed to start web server... shutting down.
org.apache.nifi.web.NiFiCoreException: Unable to start Flow Controller.
at org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:88)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:876)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:532)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:839)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:344)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1480)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1442)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:799)
at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:540)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:290)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
at org.eclipse.jetty.server.Server.start(Server.java:452)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:105)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:113)
at org.eclipse.jetty.server.Server.doStart(Server.java:419)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:695)
at org.apache.nifi.NiFi.<init>(NiFi.java:160)
at org.apache.nifi.NiFi.main(NiFi.java:267)
Caused by: java.io.IOException: Expected to read a Sentinel Byte of '1' but got a value of '0' instead
at org.apache.nifi.repository.schema.SchemaRecordReader.readRecord(SchemaRecordReader.java:65)
at org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.deserializeRecord(SchemaRepositoryRecordSerde.java:115)
at org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.deserializeEdit(SchemaRepositoryRecordSerde.java:109)
at org.apache.nifi.controller.repository.SchemaRepositoryRecordSerde.deserializeEdit(SchemaRepositoryRecordSerde.java:46)
at org.wali.MinimalLockingWriteAheadLog$Partition.recoverNextTransaction(MinimalLockingWriteAheadLog.java:1096)
at org.wali.MinimalLockingWriteAheadLog.recoverFromEdits(MinimalLockingWriteAheadLog.java:459)
at org.wali.MinimalLockingWriteAheadLog.recoverRecords(MinimalLockingWriteAheadLog.java:301)
at org.apache.nifi.controller.repository.WriteAheadFlowFileRepository.loadFlowFiles(WriteAheadFlowFileRepository.java:381)
at org.apache.nifi.controller.FlowController.initializeFlow(FlowController.java:712)
at org.apache.nifi.controller.StandardFlowService.initializeController(StandardFlowService.java:953)
at org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:534)
at org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:72)
... 28 common frames omitted
Thanks in advance
After Googling on this error "Caused by: java.io.IOException: Expected to read a Sentinel Byte of '1' but got a value of '0' instead" I found that this error indicates a partial write to the repos.
Here are a couple of things you can check/try to bring your Dataflow back online ;
check if your dsks are not full
Did you launch nifi with the same user ? Did you run it with administrator privileges ?
You can backup/move your repositories and try to start Nifi with empty repositories, you will still have your dataflows there but any file that was processing when you shutdown will be gone.
Could you please try that ?
I think the issue is with incompatible java version, use JAVA 8 version.
If you haven't set JAVA_HOME then set in environment variables with path Like "C:/program files/jdk1.8"
Jira addressing when NiFi run with java 9 version and the issue not resolved yet
https://issues.apache.org/jira/browse/NIFI-4419
I got the 5.1 Alpha release today and was unable to get it to completely start. it hangs at (or after) this log message:
INFO {org.apache.catalina.startup.TaglibUriRule} - TLD skipped. URI: http://tiles.apache.org/tags-tiles is already defined
I am starting it up with the same environment and command that I've been running. 5.0.0. sh wso2server.sh
Here is my full log.
JAVA_HOME environment variable is set to /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/
CARBON_HOME environment variable is set to /servers/wso2is-5.1.0-alpha
[2015-10-05 10:55:09,154] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Starting WSO2 Carbon...
[2015-10-05 10:55:09,155] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Operating System : Mac OS X 10.10.4, x86_64
[2015-10-05 10:55:09,155] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Home : /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
[2015-10-05 10:55:09,155] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Version : 1.7.0_79
[2015-10-05 10:55:09,155] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java VM : Java HotSpot(TM) 64-Bit Server VM 24.79-b02,Oracle Corporation
[2015-10-05 10:55:09,156] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Carbon Home : /servers/wso2is-5.1.0-alpha
[2015-10-05 10:55:09,156] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Temp Dir : /servers/wso2is-5.1.0-alpha/tmp
[2015-10-05 10:55:09,156] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - User : jsimon, en-US, America/New_York
[2015-10-05 10:55:09,259] WARN {org.wso2.carbon.core.bootup.validator.util.ValidationResultPrinter} - Carbon is configured to use the default keystore (wso2carbon.jks). To maximize security when deploying to a production environment, configure a new keystore with a unique password in the production server profile.
[2015-10-05 10:55:09,263] INFO {org.wso2.carbon.databridge.agent.thrift.AgentHolder} - Agent created !
[2015-10-05 10:55:09,279] INFO {org.wso2.carbon.databridge.agent.thrift.internal.AgentDS} - Successfully deployed Agent Client
[2015-10-05 10:55:09,405] WARN {org.wso2.carbon.identity.notification.mgt.NotificationMgtConfigBuilder} - Secret Resolver is not present. Will not resolve encryptions in config file
[2015-10-05 10:55:09,486] INFO {org.wso2.carbon.ldap.server.configuration.LDAPConfigurationBuilder} - KDC server is disabled.
[2015-10-05 10:55:12,869] INFO {org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager} - LDAP connection created successfully in read-write mode
[2015-10-05 10:55:13,180] INFO {org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService} - Configured Registry in 69ms
[2015-10-05 10:55:13,577] INFO {org.wso2.carbon.registry.core.internal.RegistryCoreServiceComponent} - Registry Mode : READ-WRITE
[2015-10-05 10:55:14,068] INFO {org.wso2.carbon.user.core.internal.UserStoreMgtDSComponent} - Carbon UserStoreMgtDSComponent activated successfully.
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Starting WSO2 Carbon...
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Operating System : Mac OS X 10.10.4, x86_64
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Home : /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Version : 1.7.0_79
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java VM : Java HotSpot(TM) 64-Bit Server VM 24.79-b02,Oracle Corporation
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Carbon Home : /servers/wso2is-5.1.0-alpha
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - Java Temp Dir : /servers/wso2is-5.1.0-alpha/tmp
[2015-10-05 10:55:14,524] INFO {org.wso2.carbon.core.internal.CarbonCoreActivator} - User : jsimon, en-US, America/New_York
[2015-10-05 10:55:18,768] INFO {org.apache.catalina.startup.TaglibUriRule} - TLD skipped. URI: http://tiles.apache.org/tags-tiles is already defined
This is at the top of the log at DEBUG level:
JAVA_HOME environment variable is set to /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/
CARBON_HOME environment variable is set to /Users/jsimon/Documents/servers/wso2is-5.1.0-alpha
[2015-10-07 07:29:22,411] DEBUG {org.wso2.carbon.context.internal.CarbonContextDataHolder} - Started Setting up Authenticator Configuration
[2015-10-07 07:29:22,573] DEBUG {org.wso2.carbon.context.internal.CarbonContextDataHolder} - Completed Setting up Authenticator Configuration
[2015-10-07 07:29:22,574] DEBUG {org.wso2.carbon.context.internal.CarbonContextDataHolder} - Unload Tenant Task: org.wso2.carbon.context.internal.CarbonContextDataHolder$CarbonContextCleanupTask was registered.
[2015-10-07 07:29:22,574] DEBUG {org.wso2.carbon.context.internal.CarbonContextDataHolder} - there can be a possibility of the same class loading twice and then trying to reset the initial context factory builder
java.lang.RuntimeException: A queue manager instance has already been set.
at org.wso2.carbon.queuing.CarbonQueueManager.setInstance(CarbonQueueManager.java:47)
at org.wso2.carbon.context.internal.CarbonContextDataHolder.<clinit>(CarbonContextDataHolder.java:200)
at org.wso2.carbon.context.CarbonContext.getThreadLocalCarbonContext(CarbonContext.java:123)
at org.wso2.carbon.utils.logging.appenders.CarbonDailyRollingFileAppender$1.run(CarbonDailyRollingFileAppender.java:55)
at org.wso2.carbon.utils.logging.appenders.CarbonDailyRollingFileAppender$1.run(CarbonDailyRollingFileAppender.java:53)
at java.security.AccessController.doPrivileged(Native Method)
at org.wso2.carbon.utils.logging.appenders.CarbonDailyRollingFileAppender.subAppend(CarbonDailyRollingFileAppender.java:53)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:197)
at org.apache.axiom.util.stax.dialect.StAXDialectDetector.detectDialect(StAXDialectDetector.java:177)
at org.apache.axiom.util.stax.dialect.StAXDialectDetector.getDialect(StAXDialectDetector.java:162)
at org.apache.axiom.util.stax.dialect.StAXDialectDetector.getDialect(StAXDialectDetector.java:154)
at org.apache.axiom.om.util.StAXUtils$7.run(StAXUtils.java:518)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axiom.om.util.StAXUtils.newXMLInputFactory(StAXUtils.java:495)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory_perClassLoader(StAXUtils.java:566)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(StAXUtils.java:172)
at org.apache.axiom.om.util.StAXUtils.getXMLInputFactory(StAXUtils.java:137)
at org.apache.axiom.om.util.StAXUtils.createXMLStreamReader(StAXUtils.java:224)
at org.apache.axiom.om.util.StAXUtils.createXMLStreamReader(StAXUtils.java:218)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.<init>(StAXOMBuilder.java:170)
at org.wso2.carbon.base.ServerConfiguration.init(ServerConfiguration.java:125)
at org.wso2.carbon.base.ServerConfiguration.forceInit(ServerConfiguration.java:216)
at org.wso2.carbon.base.internal.CarbonBaseActivator.initServerConfiguration(CarbonBaseActivator.java:68)
at org.wso2.carbon.base.internal.CarbonBaseActivator.start(CarbonBaseActivator.java:47)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Can be due to some jars being corrupted. Check the md5 of your zip distribution (md5: f96f610d7549e0285766a314e375a9f0 ) and if it matches try extracting it again. For me it works on OS X 10.9 64-bit running jdk1.7.0_79
I had the same issue with 5.1.0.. I tried with Java 8 and WSO2 starts up fine after that.
You can download zip file of the WSO2 Identity Server 5.1.0 Alpha from[1].
Extract it and successfully started the server.
[1] https://github.com/wso2/product-is/releases