zregvart added a comment - 2013-10-10 07:58 Marc, thank you for the detailed steps on how to reproduce this, I'll take a look and see what can be done.

Marc Günther added a comment - 2013-10-10 08:25 Hi, I tried to debug this back then, and if I remember correctly, your plugin set the value into the environment, but later it was overwritten by the maven buildstep. I didn't find where and how this was overwritten though, by looking at the source. Maybe there even is nothing the plugin can do about this, and it's a bug in core. And I admit this is a rather obscure use case. We already removed the existing DISPLAY variable from the slave's environment. Still it's strange that it happens only with this particular buildstep.

zregvart added a comment - 2013-10-10 18:42 Hi Marc, I'm afraid that I was unable to reproduce this following steps you outlined above. In fact, it seems to work just fine, the $DISPLAY is set to the correct value. Let me describe what I did and perhaps you could find the difference between my and your setup: I've downloaded the latest Jenkins (1.534), upgraded all plugins (at the time there were two), and installed Xvfb plugin from the experimental update site (1.0.9-beta). When launching as a SSH slave no $DISPLAY was set from .profile, in fact I think that jenkins completely replaced the environment with his own environment, if i execute env in execute shell build step no $DISPLAY was there but if I ssh into the slave the $DISPLAY was infact there (set to 99) - weird. I managed to set the $DISPLAY in the Node properties/Environment variables of the slave. Later I ssh-ed to the slave machine and run the slave as JNLP headless. In both of these cases if I've disabled the Xvfb plugin the display was set to either Node properties/Environment variables (when run as SSH slave) or to the value form .profile (when run as headles JNLP). But when I enabled the Xvfb plugin on the job I got the correct $DISPLAY set on both maven invocations, for example: Started by user anonymous Building remotely on testnode in workspace /Users/testuser/jenkins/workspace/xvfb-freestyle-test Xvfb starting$ /opt/X11/bin //Xvfb :1 -screen 0 1024x768x24 -fbdir /Users/testuser/jenkins/2013-10-10_20-18-511290154596255881707xvfb [xvfb-freestyle-test] $ /bin/sh -xe / var /folders/pj/0fsfrdhs4ws_9796wcqdf48r0000gy/T/hudson4139679048198400756.sh + cat + chmod 755 test.sh + cat + mvn -B -q compile [xvfb-freestyle-test] $ /bin/sh -xe / var /folders/pj/0fsfrdhs4ws_9796wcqdf48r0000gy/T/hudson771276611193966657.sh + echo + echo Running shell, this shows the correct output: Running shell, this shows the correct output: + mvn -B -q compile ************************* BUILD_DISPLAY_NAME=#1 DISPLAY=:1 ************************* + echo + echo Now running Maven buildstep, this shows the wrong output: Now running Maven buildstep, this shows the wrong output: [xvfb-freestyle-test] $ mvn -DDISPLAY=:1 -B -q compile ************************* BUILD_DISPLAY_NAME=#1 DISPLAY=:1 ************************* Xvfb stopping Finished: SUCCESS So, if I disable the Xvfb plugin this is how it looks: Started by user anonymous Building remotely on testnode in workspace /Users/testuser/jenkins/workspace/xvfb-freestyle-test [xvfb-freestyle-test] $ /bin/sh -xe / var /folders/pj/0fsfrdhs4ws_9796wcqdf48r0000gy/T/hudson6043730669456288268.sh + cat + chmod 755 test.sh + cat + mvn -B -q compile [xvfb-freestyle-test] $ /bin/sh -xe / var /folders/pj/0fsfrdhs4ws_9796wcqdf48r0000gy/T/hudson2700795471312004289.sh + echo + echo Running shell, this shows the correct output: Running shell, this shows the correct output: + mvn -B -q compile ************************* BUILD_DISPLAY_NAME=#2 DISPLAY=99 ************************* + echo + echo Now running Maven buildstep, this shows the wrong output: Now running Maven buildstep, this shows the wrong output: [xvfb-freestyle-test] $ mvn -B -q compile ************************* BUILD_DISPLAY_NAME=#2 DISPLAY=99 ************************* Finished: SUCCESS Can you spot any differences between this and your setup?

zregvart added a comment - 2014-03-05 10:54 Unable to reproduce

Marc Günther added a comment - 2014-03-05 11:54 Sorry, I missed your comment back then. Well, it seems that this whole thing was so rare in the first case, that it probably never happened to anyone but us. And maybe in the mean time it has been fixed already in core. So, thanks for taking the time to trying to reproduce this.