Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38840

log parser plugin fails on slave node

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: log-parser-plugin
    • Environment:
      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
    • Similar Issues:

      Description

      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)

        Attachments

        1. Selection_006.jpg
          Selection_006.jpg
          11 kB
        2. Selection_007.jpg
          Selection_007.jpg
          11 kB
        3. Selection_008.jpg
          Selection_008.jpg
          10 kB

          Activity

          Hide
          bdovaz Borja Domínguez added a comment -

          I have a similar problem. In my case if I use it like this:

           

          step([$class: 'LogParserPublisher', 
              parsingRulesPath: "{FULL_PATH}", 
              useProjectRule: false,
              failBuildOnError: true,
              unstableOnWarning: true
          ]);
          

          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)
          

           

           

          Show
          bdovaz Borja Domínguez added a comment - I have a similar problem. In my case if I use it like this:   step([$class: 'LogParserPublisher' , parsingRulesPath: "{FULL_PATH}" , useProjectRule: false , failBuildOnError: true , unstableOnWarning: true ]); 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)    
          Hide
          martinmine Martin added a comment -

          I have the same problem described by Borja Domínguez, 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 Manuel Recena Soto 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.

           

          Show
          martinmine Martin added a comment - I have the same problem described by Borja Domínguez , 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 Manuel Recena Soto 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.  
          Hide
          raguram88 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?

          Show
          raguram88 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?

            People

            • Assignee:
              mreinhardt Martin Reinhardt
              Reporter:
              stephanvdm77 Stephan van der Merwe
            • Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated: