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.

If Apple uses modified utils, their sources are on opensource.apple.com. For nohup, it's here (newest version):
http://www.opensource.apple.com/source/shell_cmds/shell_cmds-179/nohup/nohup.c

It's an error in _vprocmgr_detach_from_console which indicates the mode of installation and running Jenkins may indeed be relevant, as I know it in the context of disconnecting a process from a user session (see e.g. explanation https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard).

When installing Jenkins via installer on a virtual machine with OS X 10.7, and installing Workflow Aggregator with dependencies, the job just stops after

[workspace}Running shell script

10.7 is ancient, but it appears there's something wrong with using nohup this way. In fact, if I run a shell script with e.g. nohup find / -L -type l, I get:

Started by user anonymous
Building in workspace /Users/Shared/Jenkins/Home/jobs/nohup/workspace
[workspace] $ /bin/sh -xe /var/folders/rj/xt96v6dd5ls7v94142grnvn400007b/T/hudson3605439247319045393.sh
+ nohup find / -L -type l
nohup: can't detach from console: Inappropriate ioctl for device
Build step 'Execute shell' marked build as failure
Finished: FAILURE

Hmm. Well, I am pushing a workaround. Someone with a Mac able to reproduce this, please test this build. Not just that you can run shell scripts on a Mac node from a workflow, but that they indeed survive a Jenkins restart or slave disconnect if it is e.g. sleep 100.

JIRA link daemon is apparently dead again.

Confirmed:

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

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/durabletask/BourneShellScript.java
http://jenkins-ci.org/commit/durable-task-plugin/1957d3f51292b3e10e38ea9a400dcb8fa394d029
Log:
[FIXED JENKINS-25848] Skip nohup on Mac OS X, since it fails under some conditions.