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

Pipeline shell step aborts prematurely with ERROR: script returned exit code -1

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Minor
    • Resolution: Fixed
    • durable-task-plugin
    • None
    • durable-task 1.26

    Description

      A few of my Jenkins pipelines failed last night with this failure mode:

      01:19:19 Running on blackbox-slave2 in /var/tmp/jenkins_slaves/jenkins-regression/path/to/workspace.   [Note: this is an SSH slave]
[Pipeline] {
[Pipeline] ws
01:19:19 Running in /net/nas.delphix.com/nas/regression-run-workspace/jenkins-regression/workspace@10. [Note: This is an NFS share on a NAS]nd they shouldn't take down Jenkins jobs when they do. Our Jenkins jobs used to just hang when there was a NFS outage, now the script liveness check kills the job. I view this as a regression. As flawed
[Pipeline] {
[Pipeline] sh
01:20:10 [qa-gate] Running shell script
[... script output ...]
01:27:19 Running test_create_domain at 2017-11-29 01:27:18.887531... 
[Pipeline] // dir
[Pipeline] }
[Pipeline] // ws
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] }
[Pipeline] // timeout
ERROR: script returned exit code -1
Finished: FAILURE

      As far as I can tell the script was running fine, but apparently Jenkins killed it prematurely because Jenkins didn't think the process was still alive.

      The interesting thing is that this is normally working, but failed last night at exactly the same time in multiple pipeline jobs. And I only started seeing this after upgrading durable-task-plugin from 1.14 to 1.17. I looked at the code change and saw that the main change has been the change in ProcessLiveness from using a ps-based system to a timestamp-based system. What I suspect is that the NFS server on which this workspace is hosted wasn't processing I/O operations fast enough at the time this problem occurred, so the timestamp wasn't updated even though the script continued running. Note that I am not using Docker here, this is just a regular SSH slave.

      The ps-based approach may have been suboptimal, but it was more reliable for us than the new timestamp-based approach, at least when using NFS-based workspaces. Expecting a timestamp to increase on a file every 15 seconds may be a tall order for some system and network administrators, especially over NFS – network issues can and do happen, and they shouldn't take down Jenkins jobs when they do. Our Jenkins jobs used to just hang when there was a NFS outage, now the script liveness check kills the job. I view this as a regression. As flawed as the old approach may have been, it was immune to this failure mode. Is there anything I can do here besides increasing various timeouts to avoid hitting this? The fact that no diagnostic information was printed to the Jenkins log or the SSH slave remotin log is also problematic here.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-50892 Pipeline jobs stuck after restart

          • Major - Major loss of function.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-47791 Eliminate ProcessLiveness

          • Major - Major loss of function.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-50379 Jenkins kills long running sh script with no output

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          links to

          Web Link durable-task PR 57

          Web Link durable-task PR 81

          Web Link workflow-durable-task-step PR 62

          Activity

            Ascending order - Click to sort in descending order
            View 44 older comments
            brianjmurrell Brian J Murrell added a comment -

            I've added -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 to my Java command line but am still getting this error in my jobs.

            Here is my entire java command line:

            java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DsessionTimeout=8000 -Xms4g -Xmx8g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ParallelRefProcEnabled -XX:+UseStringDeduplication -XX:+UnlockDiagnosticVMOptions -XX:G1SummarizeRSetStatsPeriod=1 -Xloggc:/var/log/jenkins/gc-%t.log -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation -XX:GCLogFileSize=30m -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --webroot=/var/lib/jenkins/war --httpsPort=-1 --httpPort=8080 --ajp13Port=-1 -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600

             When I put the -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 before the -jar flag as such:

            java -Djava.awt.headless=true -DsessionTimeout=8000 -Xms4g -Xmx8g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ParallelRefProcEnabled -XX:+UseStringDeduplication -XX:+UnlockDiagnosticVMOptions -XX:G1SummarizeRSetStatsPeriod=1 -Xloggc:/var/log/jenkins/gc-%t.log -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation -XX:GCLogFileSize=30m -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --webroot=/var/lib/jenkins/war --httpsPort=-1 --httpPort=8080 --ajp13Port=-1

             Jenkins just doesn't start. The java process starts and runs but nothing is added to jenkins.log and nothing is listening on the web interface.

            Any ideas?

            brianjmurrell Brian J Murrell added a comment - I've added -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 to my Java command line but am still getting this error in my jobs. Here is my entire java command line: java -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true -DsessionTimeout=8000 -Xms4g -Xmx8g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ParallelRefProcEnabled -XX:+UseStringDeduplication -XX:+UnlockDiagnosticVMOptions -XX:G1SummarizeRSetStatsPeriod=1 -Xloggc:/var/log/jenkins/gc-%t.log -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation -XX:GCLogFileSize=30m -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --webroot=/var/lib/jenkins/war --httpsPort=-1 --httpPort=8080 --ajp13Port=-1 -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600  When I put the -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 before the -jar flag as such: java -Djava.awt.headless=true -DsessionTimeout=8000 -Xms4g -Xmx8g -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ParallelRefProcEnabled -XX:+UseStringDeduplication -XX:+UnlockDiagnosticVMOptions -XX:G1SummarizeRSetStatsPeriod=1 -Xloggc:/var/log/jenkins/gc-%t.log -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation -XX:GCLogFileSize=30m -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCCause -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=3600 -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --webroot=/var/lib/jenkins/war --httpsPort=-1 --httpPort=8080 --ajp13Port=-1  Jenkins just doesn't start. The java process starts and runs but nothing is added to jenkins.log and nothing is listening on the web interface. Any ideas?
            jglick Jesse Glick added a comment -

            brianjmurrell yes my explanation was about how to start diagnosing issues in this class, given sufficient knowledge of Jenkins internals. The result of such a diagnosis would be understanding of one new kind of environmental problem that leads to this symptom, and thus a new issue report and an idea for a product patch to either recover automatically or display a user-friendly error. If you are encountering this error on current versions of durable-task, it is likely that your problem is not a laggy filesystem, but something unrelated and yet to be identified.

            jglick Jesse Glick added a comment - brianjmurrell yes my explanation was about how to start diagnosing issues in this class, given sufficient knowledge of Jenkins internals. The result of such a diagnosis would be understanding of one new kind of environmental problem that leads to this symptom, and thus a new issue report and an idea for a product patch to either recover automatically or display a user-friendly error. If you are encountering this error on current versions of durable-task , it is likely that your problem is not a laggy filesystem, but something unrelated and yet to be identified.
            w60001 Christopher Shannon added a comment -

            In case it helps anyone else who stumbles across this thread, I just ran into this problem and was able to figure out why (which was not a durable-step, or Jenkins thing, but something I was doing wrong).

            I basically had three different stages in my pipeline using static code analysis tools.  Each of these tools can be CPU intensive and by default are happy to consume as many cores as are available on the host.  We also have multiple Jenkins executors for each of our nodes (e.g. 4 executors on a 4 core node).

            This problem presented itself when I put these three stages in a parallel block, and they all mapped to three executors on the same physical node.  When they started analyzing the code, I'm sure that my system load was completely railed (i.e. 2 if not 3 processes each trying to peg every core to 100% CPU).

            It is no surprise that this error message would occur in this scenario.  Sure, Jenkins could have been more patient, but it also pointed to a pipeline architecture problem on my end.

            w60001 Christopher Shannon added a comment - In case it helps anyone else who stumbles across this thread, I just ran into this problem and was able to figure out why (which was not a durable-step, or Jenkins thing, but something I was doing wrong). I basically had three different stages in my pipeline using static code analysis tools.  Each of these tools can be CPU intensive and by default are happy to consume as many cores as are available on the host.  We also have multiple Jenkins executors for each of our nodes (e.g. 4 executors on a 4 core node). This problem presented itself when I put these three stages in a parallel block, and they all mapped to three executors on the same physical node.  When they started analyzing the code, I'm sure that my system load was completely railed (i.e. 2 if not 3 processes each trying to peg every core to 100% CPU). It is no surprise that this error message would occur in this scenario.  Sure, Jenkins could have been more patient, but it also pointed to a pipeline architecture problem on my end.
            msa Michael Schaufelberger added a comment - - edited

            Thank you for the Workaround via Script Console, rodrigc!

            Note: The second argument had to be a String in my case: "3600".

            msa Michael Schaufelberger added a comment - - edited Thank you for the Workaround via Script Console, rodrigc ! Note: The second argument had to be a String in my case: "3600" .
            bbourdin Benoit Bourdin added a comment -

            For people who are still experiencing this error message, please check the details of some other possible causes here.

            bbourdin Benoit Bourdin added a comment - For people who are still experiencing this error message, please check the details of some other possible causes here .

            People

              jglick Jesse Glick
              basil Basil Crow
              Votes:
              6 Vote for this issue
              Watchers:
              33 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: