-
Bug
-
Resolution: Unresolved
-
Major
-
Operating system: Ubuntu 16.04
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+134)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+134, mixed mode)
Jenkins ver. 2.7.4
Log parser plugin 2.0
Steps taken:
1. I installed the log parser plugin,
2. Setup my rules file on the master.
3. created a job/build to run on a slave
4. For this job, setup post-build actions with console output log parsing
5. mark build failed on error
6. Use global rules
7. selected my rule file.
When I execute the job, the job runs successfully however the log parsing failed.
Clicking on the Parsed Console Output option, I get the following.
ERROR: Failed to parse console log
java.io.IOException: Remote call on centos7 failed
So it looks like the log parser plugin cannot communicate with the slave node to get log output.
Please help, this is so frustrating when things don't work as they should.
Below is the output of the error in the jenkins.log
Oct 08, 2016 11:13:36 AM hudson.plugins.logparser.LogParserPublisher perform
SEVERE: log-parser plugin ERROR: Cannot parse log POCProject/TestJob #19
java.io.IOException: Remote call on centos7 failed
at hudson.remoting.Channel.call(Channel.java:789)
at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:47)
at hudson.plugins.logparser.LogParserStatusComputer.<init>(LogParserStatusComputer.java:36)
[JENKINS-38840] log parser plugin fails on slave node
Martin
added a comment - I have the same problem described by bdovaz, but are we really guaranteed that the plugin will search on the master node? What happens if the master node has no free executors, but one of the build slaves are free?
The following pipeline script reproduces the issue we are having:
node('centos7') { git url: 'https://github.com/somewhere/something.git' step([$class: 'LogParserPublisher', parsingRulesPath: "${pwd()}/LogParserRules.txt", useProjectRule: false, unstableOnWarning: false, failBuildOnError: true]) }
As far as I see, the main problem is that the log parser is looking for the log parser depending on where the "master" job is executing. As recena describes, this happens for freestyle jobs when you configure the jobs to run somewhere else than on the master. With pipelines, it appears that it expects them to be on the master node, but I think there might even be a chance it could look for it somewhere else as well in case the master has no free executors when the pipeline starts.
For pipelines, one possible solution would be to have a section that runs on the master node to parse the log:
node('centos7') { // Build our project here } // Parse the logs on the master node node('master') { git url: 'https://github.com/somewhere/something.git' step([$class: 'LogParserPublisher', parsingRulesPath: "${pwd()}/LogParserRules.txt", useProjectRule: false, unstableOnWarning: false, failBuildOnError: true]) }
This has some disadvantages:
- We need to occupy a free executor just to parse logs.
- If the master node has no free executors, our build gets blocked.
- Need to unstash or clone a git repo containing the log parser rule (or somehow get it from somewhere).
- Are we for certain that the log parser will look for the log on the master node? If this is not the case, the pipeline script above would not even be reliable.
Martin
added a comment - I have the same problem described by bdovaz , but are we really guaranteed that the plugin will search on the master node? What happens if the master node has no free executors, but one of the build slaves are free?
The following pipeline script reproduces the issue we are having:
node( 'centos7' ) {
git url: 'https: //github.com/somewhere/something.git'
step([$class: 'LogParserPublisher' ,
parsingRulesPath: "${pwd()}/LogParserRules.txt" ,
useProjectRule: false ,
unstableOnWarning: false ,
failBuildOnError: true ])
}
As far as I see, the main problem is that the log parser is looking for the log parser depending on where the "master" job is executing. As recena describes, this happens for freestyle jobs when you configure the jobs to run somewhere else than on the master. With pipelines, it appears that it expects them to be on the master node, but I think there might even be a chance it could look for it somewhere else as well in case the master has no free executors when the pipeline starts.
For pipelines, one possible solution would be to have a section that runs on the master node to parse the log:
node( 'centos7' ) {
// Build our project here
}
// Parse the logs on the master node
node( 'master' ) {
git url: 'https: //github.com/somewhere/something.git'
step([$class: 'LogParserPublisher' ,
parsingRulesPath: "${pwd()}/LogParserRules.txt" ,
useProjectRule: false ,
unstableOnWarning: false ,
failBuildOnError: true ])
}
This has some disadvantages:
We need to occupy a free executor just to parse logs.
If the master node has no free executors, our build gets blocked.
Need to unstash or clone a git repo containing the log parser rule (or somehow get it from somewhere).
Are we for certain that the log parser will look for the log on the master node? If this is not the case, the pipeline script above would not even be reliable.
Ragu Raman S
added a comment - I also have the same issue and looks like Log parser rules are referred only from Master(this plugin doesn't support to configure parser rules in slave machines) - any workaround/solution?
Ragu Raman S
added a comment - I also have the same issue and looks like Log parser rules are referred only from Master(this plugin doesn't support to configure parser rules in slave machines) - any workaround/solution?
I have a similar problem. In my case if I use it like this:
For "parsingRulesPath" it's searching on master and not in the current running node like it's expected.
Also then I get this error (I also don't know why it reads from "builds\1\log" because if my build steps are splitted between slaves that log parts are going to be on several machines):
java.lang.SecurityException: agent may not read {MY_PIPELINE_PROJECT}\builds\1\log See https://jenkins.io/redirect/security-144 for more details at jenkins.SoloFilePathFilter.noFalse(SoloFilePathFilter.java:31) at jenkins.SoloFilePathFilter.read(SoloFilePathFilter.java:37) at hudson.FilePath.reading(FilePath.java:2852) at hudson.FilePath.access$200(FilePath.java:195) at hudson.FilePath$41.invoke(FilePath.java:2010) at hudson.FilePath$41.invoke(FilePath.java:2005) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at org.jenkinsci.remoting.CallableDecorator.call(CallableDecorator.java:19) at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at ......remote call to JNLP4-connect connection to {MY_SERVER} (Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:830) at hudson.FilePath.act(FilePath.java:985) at hudson.FilePath.act(FilePath.java:974) at hudson.FilePath.copyTo(FilePath.java:2005) at hudson.FilePath.copyTo(FilePath.java:1981) at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:88) at hudson.plugins.logparser.LogParserStatusComputer.access$000(LogParserStatusComputer.java:22) at hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:54) at hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:47) at hudson.remoting.UserRequest.perform(UserRequest.java:153) at hudson.remoting.UserRequest.perform(UserRequest.java:50) at hudson.remoting.Request$2.run(Request.java:336) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:94) at java.lang.Thread.run(Unknown Source) at ......remote call to JNLP4-connect connection from 192.168.3.138/192.168.3.138:63307(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545) at hudson.remoting.UserResponse.retrieve(UserRequest.java:253) at hudson.remoting.Channel.call(Channel.java:830) at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:47) at hudson.plugins.logparser.LogParserStatusComputer.<init>(LogParserStatusComputer.java:36) at hudson.plugins.logparser.LogParserParser.parseLogBody(LogParserParser.java:309) at hudson.plugins.logparser.LogParserParser.parseLog(LogParserParser.java:134) at hudson.plugins.logparser.LogParserPublisher.perform(LogParserPublisher.java:131) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:78) at org.jenkinsci.plugins.workflow.steps.CoreStep$Execution.run(CoreStep.java:65) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:49) at hudson.security.ACL.impersonate(ACL.java:260) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)