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

Batch step running on a node other than the master fails

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Running a batch command on another node takes several minutes and then fails. Attached example (all Windows, the echo command won't print):

      stage('1') {
        node('uitest') {
          bat 'echo something'
        }
      }
      

      After 10 minutes the console output prompts this and the build fails:

      ERROR: script apparently exited with code 0 but asynchronous notification was lost

      In addition the system log gets these exceptions:

      • java.lang.NoClassDefFoundError: Could not initialize class hudson.slaves.SlaveComputer
      • hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Florian Ramillien

            in my case it's huge logs files

            Then you may rather have hit a symptom of JENKINS-54073, whereas other reporters (Bhushan Shah, Éric Louvard, mishal shah, but again excluding the false initial report by Yoav Miles) seem to have hit something very different.

            Show
            jglick Jesse Glick added a comment - Florian Ramillien in my case it's huge logs files Then you may rather have hit a symptom of JENKINS-54073 , whereas other reporters ( Bhushan Shah , Éric Louvard , mishal shah , but again excluding the false initial report by Yoav Miles ) seem to have hit something very different.
            Hide
            jglick Jesse Glick added a comment -

            Anyone still seeing this using up-to-date plugins and -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=true? If so, please make sure you have custom loggers set up as in my comment of 2018-10-25 and see if the problem can be reproduced in a clean environment.

            Show
            jglick Jesse Glick added a comment - Anyone still seeing this using up-to-date plugins and -Dorg.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep.USE_WATCHING=true ? If so, please make sure you have custom loggers set up as in my comment of 2018-10-25 and see if the problem can be reproduced in a clean environment.
            Hide
            shriramd Shriram Datar added a comment -

            I am seeing the same issue with the latest Jenkins+ all up to date plugins. I am running only echo 1234 in the batch file. I have exact same logs as attached to this ticket

             

            Show
            shriramd Shriram Datar added a comment - I am seeing the same issue with the latest Jenkins+ all up to date plugins. I am running only echo 1234 in the batch file. I have exact same logs as attached to this ticket  
            Hide
            amol_malokar milo6 added a comment -

            I change from 32 bit to 64 bit Java and Increased JVM heap size to 4GB seems to be working . 

            Show
            amol_malokar milo6 added a comment - I change from 32 bit to 64 bit Java and Increased JVM heap size to 4GB seems to be working . 
            Hide
            jglick Jesse Glick added a comment -

            Shriram Datar if you are seeing the java.lang.NoClassDefFoundError: Could not initialize class hudson.slaves.SlaveComputer then, like the original reporter, this suggests that you were using an incompatible JRE for the agent—a problem which the switch to watching mode might have incidentally triggered, but not really caused. milo6’s issue sounds similar—possibly the use of 32-bit Java led to some incompatibility with JNA that would up crashing a lot of class loading. Hard to know without being able to reproduce from scratch, including details of the Java installation packages used.

            Show
            jglick Jesse Glick added a comment - Shriram Datar if you are seeing the java.lang.NoClassDefFoundError: Could not initialize class hudson.slaves.SlaveComputer then, like the original reporter, this suggests that you were using an incompatible JRE for the agent—a problem which the switch to watching mode might have incidentally triggered, but not really caused. milo6 ’s issue sounds similar—possibly the use of 32-bit Java led to some incompatibility with JNA that would up crashing a lot of class loading. Hard to know without being able to reproduce from scratch, including details of the Java installation packages used.

              People

              • Assignee:
                Unassigned
                Reporter:
                towel Yoav Miles
              • Votes:
                6 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated: