-
Improvement
-
Resolution: Fixed
-
Major
While trying to diagnose the failure of the timeout step to terminate a process (see process tree, the Pipeline was awaiting completion of pid 1031) with jglick we determined that the timeout step doesn't include sufficient information in the logs of the Pipeline Thread Dump to be terrifically useful when things go awry.
See the following chat log:
16:39 < jglick> rtyler: so that was a normal termination via `SIGTERM` (143 = 128 + 15; cf. `kill -l`). Not sure why `timeout` did not do it. No Jenkins restart that I can see. Could try to add more status information to `timeout` indicating in virtual thread dump (a) whether it ever delivered a cancellation, (b) whether its scheduled task is still there. 16:40 <@rtyler> jglick: should adding more verbiage to timeout be among the tickets I should file/ 16:40 < jglick> rtyler: that would be in `workflow-basic-steps-plugin`; `sh` is in `workflow-durable-task-step-plugin` 16:41 < jglick> rtyler: verbiage in the log, but also information in virtual thread dump (currently it does not override `getStatus`)
The more information the timeout step can include in both the Console Output and the Thread Dump, the better.
Potentially related to JENKINS-34637
- is duplicated by
-
JENKINS-39266 Timeout occurence inside a retry step wont cancel the latter
- Resolved
-
JENKINS-32228 Event when timeout is reach should be customizable
- Resolved
- is related to
-
JENKINS-25504 Failing a Step with a body while the body is running breaks FlowNodeGraph
- Resolved
- relates to
-
JENKINS-34637 pipeline DSL: timeout() does not work if withEnv() is enclosed
- Resolved
-
JENKINS-42940 Timeout step hangs after restart if timeout occurred, but enclosed block did not exit yet
- Resolved
- links to