Started by user anonymous
Building in workspace /Users/danielbeck/JENKINS-27178-Home/workspace/JENKINS-27178
JENKINS-27178 $ /bin/sh -xe /var/folders/39/ggldtdps6034ct7d_y6x4_v80000gn/T/hudson3952789379184431267.sh
+ sleep 59

+ echo 'sleep done'
sleep done
Finished: SUCCESS

Works for me with a pristine Jenkins 1.600 and new home directory, freestyle job run on master.

Could you try to reproduce this issue on a (mostly) new Jenkins instance, and/or try to figure out what part of your environment breaks this? Maybe there's something interesting in the slave log? jenkins.log? The system logs of the slave node?

Some times it works for me as well, it seems to be when I run with multiple executors and even without the slaves there are problems.

so recreating the problem is not that easy.

we have quite a lot of plugins installed, so it's not that easy to recreate the setup and the problem, and it looks like the changes in the 1.600 release are to blame

if none of that gives you any clues, i'll try setting a vagrant box up with a copy of my setup so I have somewhere I can try to recreate the errors and get back to you.

Having the same problem since upgrading to 1.600 from 1.599. A certain shell invocation completes normally, but Jenkins occasionally reports a FAILURE for no good reason.

I upgraded to 1.600 this afternoon and immediately began experiencing this issue. Downgrading works, but all our job history disappears when I do that. Since we make heavy use of 'execute shell' I am not sure what to do next except restore from backup.

You could try to isolate the cause. As I wrote above, I was unable to reproduce this issue on a test instance (even when running two builds of different jobs in parallel on the master node).

I've been able to reproduce this issue on a test instance of 1.600 only when env-inject is installed and enabled. Disable it, restart, issue is gone. Enable it, restart, issue is back.

It seems to occur when two builds (different projects but same config, only the sleep + echo shell step) run in parallel (on the master node for me). There's a solid chance that one of the two (never both so far) fails.

Presumably related to JENKINS-26755 so tentatively assigning to ndeloof. Given how popular this plugin is this can easily blow up a lot of instances, especially assuming that users who care about Jenkins security upgrade earlier than usual due to the security advisory.

If anyone's interested and capable, it should be easy enough to revert the changes for JENKINS-26755 and create a build of 1.600 without it to see whether it resolves the issue for you. I could also provide such a build if you're willing to trust some random guy on the internet. Just respond here.

Possible fix in core:

$ git diff
diff --git a/core/src/main/java/hudson/model/Computer.java b/core/src/main/java/hudson/model/Computer.java
index 2d31b41..058a166 100644
--- a/core/src/main/java/hudson/model/Computer.java
+++ b/core/src/main/java/hudson/model/Computer.java
@@ -948,12 +948,12 @@ public /*transient*/ abstract class Computer extends Actionable implements Acces
     public EnvVars getEnvironment() throws IOException, InterruptedException {
         EnvVars cachedEnvironment = this.cachedEnvironment;
         if (cachedEnvironment != null) {
-            return cachedEnvironment;
+            return new EnvVars(cachedEnvironment);
         }
 
         cachedEnvironment = EnvVars.getRemote(getChannel());
         this.cachedEnvironment = cachedEnvironment;
-        return cachedEnvironment;
+        return new EnvVars(cachedEnvironment);
     }
 
     /**

Only tested this issue with this change, I'm not entirely sure there are no further side effects.

Someone else can write the tests for this