-
Bug
-
Resolution: Fixed
-
Critical
Simple hello world from workflow-plugin
node {
sh 'echo hello world'
}
fails
Running: Allocate node : Start Running on master in /Users/Shared/Jenkins/Home/jobs/workflow/workspace Running: Allocate node : Body : Start Running: Shell Script [workspace] Running shell script nohup: can't detach from console: No such file or directory Aborted by asdf Aborted by asdf Running: Allocate node : Body : End Running: Allocate node : End Running: End of Workflow Finished: ABORTED
- is related to
-
-
- Resolved
-
- relates to
-
JENKINS-33708 Invocation of 'sh' on Windows should provide a more helpful error
-
- Fixed but Unreleased
-
[JENKINS-25848] Shell step fails on Mac: nohup: can't detach from console: No such file or directory
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.
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.
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.
A fix of
JENKINS-25503would 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.