A fix of JENKINS-25503 would supersede this, but there may be a simpler short-term fix, if this can be reproduced by other Mac users. (Can it?)

Fortunately it seems my logic in DurableTaskStep to do a hard kill on the second abort is working here, and allows the flow to at least be cleanly killed.

Started by user anonymous
Running: Allocate node : Start
Running on master in /Users/danielbeck/Workflow-Home/jobs/wf/workspace
Running: Allocate node : Body : Start
Running: Shell Script
[workspace] Running shell script
+ echo hello world
hello world
Running: Allocate node : Body : End
Running: Allocate node : End
Running: End of Workflow
Finished: SUCCESS

Make sure your PATH contains /usr/bin.

Do you use default macos installer?

No, see the Jenkins home directory path. I ran java -jar jenkins.war with a pristine Jenkins home directory. I'm just pointing out that either there's something exceptionally wrong with your setup (hence my suggestion to look into PATH), and/or there's some other condition to reproduce this that is unknown so far. "It doesn't work on OS X" as this issue seems to imply is simply not the case.

The error message does not suggest a problem with $PATH, but some other problem with nohup, perhaps related to the controlling terminal. Running from the native installer as opposed to using java -jar jenkins.war in a shell is certainly a plausible distinction here.

When i run standard "shell execution" build step, then it has "PATH=/Users/Shared/Jenkins/Home/tools/hudson.model.JDK/bin:/usr/bin:/bin:/usr/sbin:/sbin".

Sure. The question is whether the bug only appears when using the installer, which I presume starts some kind of system service, as opposed to running jenkins.war from a shell. And whether the bug is reproducible (in either or both Jenkins startup modes) when the build is run on a slave—even one on the same Mac system, but using the SSH launcher so that the process hierarchy is rooted at the SSH daemon.

By the way searches for nohup: can't detach from console turn up various hits, all specific to Mac OS X, though not this exact error message. Unfortunately the message fails to specify which file or directory could not be found; as a C app there is no stack trace either. I could not find this error here; perhaps Mac OS X ships with a proprietary version of this tool.

The simplest fix would probably just be to remove the use of nohup, at least when running on Mac OS X, as it may not really be effective anyway (cf. JENKINS-25503): our main concern is preventing SIGTERM on the master or slave process from being applied to child processes, whereas SIGHUP is less likely to be sent to begin with. However before doing that I would like to ascertain how serious of an issue this is, by checking under what conditions it is reproducible.