jenkinsci / jenkinsci/durable-task-plugin

[JENKINS-53750] Shell scripts keep the working directory locked on Windows

Open
#441 3 comments 0 reactions 0 assignees View on GitHub
component:durable-task-plugin component:workflow-durable-task-step-plugin imported-jira-issue pipeline priority:major resolution:unresolved
Dominant language
Java
Stars
30
Forks
101
PR merge metrics
No merged PRs in 30d

Description

Try to run the following pipeline on a Windows node (you'll need a Unix shell port; I am using bash from Git for Windows):

node('mynode') {

stage('Test') {
dir('foo/bar') { sh 'sleep 1' }
bat 'rename foo baz'
}
}

The bat step will fail with an "Access is denied" message.

It seems that the reason for this is that when the Durable Task plugin runs its wrapper script (in BourneShellScript.launchWithCookie), it doesn't wait for the wrapper process to finish before it allows pipeline execution to proceed to the next step. It only waits until the result file gets created. This means that for a fraction of time, the bat step will be running concurrently with these three processes created for the sh step:


  1. The wrapper script.

  2. The nohup process that is its parent.

  3. The background job that the wrapper script creates to periodically touch the log file.

And that fraction can be significant, because the background job sleeps in intervals of three seconds.

Now, those processes have as their working directory the directory of the sh step, which on Windows means that that directory is locked - it cannot be deleted, and its parent cannot be moved. And since the bat step starts executing before those processes terminate, it cannot rename the foo directory, even though it really should be able to.

To solve this, ideally, the Durable Task plugin should wait for the nohup process to terminate before proceeding with the next step. Failing that, it should at least make sure that the working directories of the auxiliary processes it spawns aren't within the workspace.

(I'm unable to easily test this using the most recent version of the plugin, but I reviewed the changes made since 1.22 and I'm fairly confident that the latest version still exhibits this issue.)

---
Originally reported by rdonchen_intel, imported from: Shell scripts keep the working directory locked on Windows


  • status: Open
  • priority: Major
  • component(s): durable-task-plugin, workflow-durable-task-step-plugin
  • label(s): pipeline, sh, triaged-2018-11, windows
  • resolution: Unresolved
  • votes: 0
  • watchers: 3
  • imported: 2025-12-09

Raw content of original issue

Try to run the following pipeline on a Windows node (you'll need a Unix shell port; I am using bash from Git for Windows):


node('mynode') {

stage('Test') {
dir('foo/bar') { sh 'sleep 1' }
bat 'rename foo baz'
}
}

The bat step will fail with an "Access is denied" message.

It seems that the reason for this is that when the Durable Task plugin runs its wrapper script (in BourneShellScript.launchWithCookie), it doesn't wait for the wrapper process to finish before it allows pipeline execution to proceed to the next step. It only waits until the result file gets created. This means that for a fraction of time, the bat step will be running concurrently with these three processes created for the sh step:


  1. The wrapper script.

  2. The nohup process that is its parent.

  3. The background job that the wrapper script creates to periodically touch the log file.

And that fraction can be significant, because the background job sleeps in intervals of three seconds.

Now, those processes have as their working directory the directory of the sh step, which on Windows means that that directory is locked - it cannot be deleted, and its parent cannot be moved. And since the bat step starts executing before those processes terminate, it cannot rename the foo directory, even though it really should be able to.

To solve this, ideally, the Durable Task plugin should wait for the nohup process to terminate before proceeding with the next step. Failing that, it should at least make sure that the working directories of the auxiliary processes it spawns aren't within the workspace.

(I'm unable to easily test this using the most recent version of the plugin, but I reviewed the changes made since 1.22 and I'm fairly confident that the latest version still exhibits this issue.)

environment

```
Jenkins 2.138.1

Durable Task plugin 1.22
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.