Details
-
Bug
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
Jenkins 1.625.3
Amazon EC2 plugin 1.31
Master and slaves running Ubuntu 14.04
Description
I noticed my Unix slaves on EC2 do not have a ~/.hudson-run-init file, despite running the init script (and following setup steps) successfully. As a result, when they're brought back up from a stopped state, they run the init script again, wasting ~20 minutes.
Some relevant AMI configuration:
- Remote FS root: /home/ubuntu
- Remote user: ubuntu
- AMI Type: unix
- Root command prefix: sudo
- Init script is essentially: sudo $HOME/init_script.sh
On a successfully connected slave, I expect to see /home/ubuntu/.hudson-run-init, but there's no such file. I took a quick look at EC2UnixLauncher.java, and everything looks reasonable. My only question is why touch ~/.hudson-run-init would need to be run as root. But both touch ~/.hudson-run-init and sudo touch ~/.hudson-run-init produce the expected file when run manually as the ubuntu user. So I'm a bit stumped.
I'm testing out touching the file myself in the init script as a workaround.
Attachments
Activity
Patrick Mihelich
created issue -
| Field | Original Value | New Value |
|---|---|---|
| Workflow | JNJira [ 169361 ] | JNJira + In-Review [ 183465 ] |
Perrin Morrow
added a comment - Well "more testing next week" turned into two years, sorry about that.
I've pushed the code we've been running with for those two years in this pull request.
Perrin Morrow
added a comment - Well "more testing next week" turned into two years, sorry about that.
I've pushed the code we've been running with for those two years in this pull request .
Raihaan Shouhell
added a comment - PR has been merged if this is still an issue please reopen this with a new version of the plugin
Raihaan Shouhell
added a comment - PR has been merged if this is still an issue please reopen this with a new version of the plugin Raihaan Shouhell
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
We've been seeing this behaviour too, but not consistently. Some of the time the file is created, and I can't see any obvious pattern.
I am currently running a patched version of the plugin in our staging environment, with extra logging around the creation of the file to see why it might be failing. But so far it has created the file every time.
It's possible my call to
which I added to get the exit status may have caused it to work more reliably.
I'll do some more testing next week.