Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19950

DISPLAY variable is not overwritten when it already exists

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Cannot Reproduce
    • Component/s: xvfb-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      This is a followup to JENKINS-17127

      For a freestyle project with an "Invoke top-level Maven targets" build step and the Xvfb plugin enabled, the DISPLAY environment variable is not set when it already exists in the environment of the slave.

      To reproduce:

      • create a slave with an existing environment variable: DISPLAY=:99
        eg. by setting this in the .profile of the slave
      • create a freestyle job with the attached config, which basically:
        • contains a pom which outputs the DISPLAY environment variable
        • creates two buildsteps, a shell which executes mvn and a Maven buildstep doing the same.

      I get the correct output (eg. DISPLAY=:1) from the shell build step, and the wrong output (DISPLAY=:99) from the maven buildstep.

      BTW, I also tried a Maven Job, and it works there, too. The only problem exists in a maven buildstep in a freestyle job.

        Attachments

          Activity

          Hide
          zregvart zregvart added a comment -

          Marc, thank you for the detailed steps on how to reproduce this, I'll take a look and see what can be done.

          Show
          zregvart zregvart added a comment - Marc, thank you for the detailed steps on how to reproduce this, I'll take a look and see what can be done.
          Hide
          marc_guenther Marc Günther added a comment -

          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.

          Show
          marc_guenther Marc Günther added a comment - 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.
          Hide
          zregvart zregvart added a comment -

          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?

          Show
          zregvart zregvart added a comment - 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?
          Hide
          zregvart zregvart added a comment -

          Unable to reproduce

          Show
          zregvart zregvart added a comment - Unable to reproduce
          Hide
          marc_guenther Marc Günther added a comment -

          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.

          Show
          marc_guenther Marc Günther added a comment - 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.

            People

            Assignee:
            zregvart zregvart
            Reporter:
            marc_guenther Marc Günther
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: