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

Job continues to run on timeout when process exits with code 0

      When a sh step, wrapped into a timeout step exits with code 0 when it receives a SIGTERM or SIGINTER signal, the job will continue to run and not abort.

       

      I expected that when the timeout expires, the job terminates, independent from the exit code of the process that was terminated by the timeout.
      This breaks the timeout functionality for processes that behaves badly (exit with wrong signal) or ignore the signal but terminate soon afterwards.

       

      How to reproduce:

      pipeline {
        agent any  stages {
         stage("Test") {
             steps {
             timeout(time: 3, unit: 'SECONDS') {
               script {
                 def rc = sh(
                 script: '''#!/bin/bash
                 
                 trap 'exit 0' INT TERM
                 
                 while true; do
                     echo "Sleeping..."
                     sleep 1
                 done
                 ''')
               }
             }
             echo "echo after TIMEOUT, job still running"
           }
          }
        }
      }
      

          [JENKINS-71481] Job continues to run on timeout when process exits with code 0

          Mark Waite added a comment - - edited

          I believe this is a user misunderstanding or a gap in the documentation. When an sh step returns status, it is assumed that the Pipeline that called the sh step will set the job status based on that result.

          The following abbreviated Pipeline shows the same:

          pipeline {
              agent {
                  label '!windows'
              }
              stages {
                  stage('Hello') {
                      steps {
                          echo 'Hello World'
                          script {
                              def rc = sh(returnStatus: true, script: 'exit 1')
                              echo "return code is ${rc}"
                          }
                          echo 'After the shell step'
                      }
                  }
              }
          }
          

          Even though the shell step exits with a non-zero exit code, the Pipeline script continues to run because it is expected that the Pipeline script will decide if it should stop the Pipeline or continue.

          If you are using returnStatus: true with the sh step, then I believe it is assumed that you'll also mark the job as unstable or failed as appropriate based on the status returned by the sh step.

          Mark Waite added a comment - - edited I believe this is a user misunderstanding or a gap in the documentation. When an sh step returns status, it is assumed that the Pipeline that called the sh step will set the job status based on that result. The following abbreviated Pipeline shows the same: pipeline { agent { label '!windows' } stages { stage('Hello') { steps { echo 'Hello World' script { def rc = sh(returnStatus: true, script: 'exit 1') echo "return code is ${rc}" } echo 'After the shell step' } } } } Even though the shell step exits with a non-zero exit code, the Pipeline script continues to run because it is expected that the Pipeline script will decide if it should stop the Pipeline or continue. If you are using returnStatus: true with the sh step, then I believe it is assumed that you'll also mark the job as unstable or failed as appropriate based on the status returned by the sh step.

          Fabian Holler added a comment - - edited

          markewaite The behavior is the same without returnStatus: false. When the timeout expires and the command exits with code 0, the job continues.

          I would expect with and also without returnStatus that the job does not continue if the timeout expires.

           

          I'll update the example in the ticket description, having returnStatus in it is distracting. 

          Fabian Holler added a comment - - edited markewaite The behavior is the same without returnStatus: false. When the timeout expires and the command exits with code 0, the job continues. I would expect with and also without returnStatus that the job does not continue if the timeout expires.   I'll update the example in the ticket description, having returnStatus in it is distracting. 

            Unassigned Unassigned
            fho Fabian Holler
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: