• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • xvfb-plugin
    • None

      When a connection to a slave is unexpectedly broken during a build, an Xvfb process started by the plugin is not killed. After the slave is reconnected, subsequent builds on it fail immediately because the plugin tries to start a new Xvfb process on the same display as the old one.

      It would be helpful if the plugin could kill left over Xvfb processes before trying to start a new one. There could be a configuration option to kill all Xvfb processes. More robustly, it could probably find just the problematic one by command line.

          [JENKINS-20758] Xvfb processes remain after slave disconnect

          Code changed in jenkins
          User: Zoran Regvart
          Path:
          src/main/java/org/jenkinsci/plugins/xvfb/XvfbBuildWrapper.java
          src/main/java/org/jenkinsci/plugins/xvfb/XvfbEnvironment.java
          src/main/resources/org/jenkinsci/plugins/xvfb/Messages.properties
          http://jenkins-ci.org/commit/xvfb-plugin/4137f5c1f6b262ca878005a07cbf270d2c0bcaf9
          Log:
          JENKINS-20758 Xvfb processes remain after slave disconnect

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Zoran Regvart Path: src/main/java/org/jenkinsci/plugins/xvfb/XvfbBuildWrapper.java src/main/java/org/jenkinsci/plugins/xvfb/XvfbEnvironment.java src/main/resources/org/jenkinsci/plugins/xvfb/Messages.properties http://jenkins-ci.org/commit/xvfb-plugin/4137f5c1f6b262ca878005a07cbf270d2c0bcaf9 Log: JENKINS-20758 Xvfb processes remain after slave disconnect

          zregvart added a comment -

          Hi Jonathan,
          thanks for reporting this, I would have probably never come across this. I've made a change in the way the plugin handles shutdown of Xvfb: it now detects the communication failure on shutdown, and keeps a list of Xvfb processes that need to be killed when the offending node comes back online. So when the node is back online the zombie Xvfb process will be (attempted to be) killed, and the temporary frame buffer directory will be deleted.
          This does not help in case of master failure because the list is not persisted, but in that case you master fails I guess that you have greater problems than zombie Xvfb processes.
          I've tested this by killing ssh connection between master and the slave, I would be very grateful if you could test it in your setup as well.
          You'll need to use the experimental update site (http://updates.jenkins-ci.org/experimental/update-center.json) configured in the Advanced tab of the Plugin manager, the released version is 1.0.9-beta-2.

          Zoran

          zregvart added a comment - Hi Jonathan, thanks for reporting this, I would have probably never come across this. I've made a change in the way the plugin handles shutdown of Xvfb: it now detects the communication failure on shutdown, and keeps a list of Xvfb processes that need to be killed when the offending node comes back online. So when the node is back online the zombie Xvfb process will be (attempted to be) killed, and the temporary frame buffer directory will be deleted. This does not help in case of master failure because the list is not persisted, but in that case you master fails I guess that you have greater problems than zombie Xvfb processes. I've tested this by killing ssh connection between master and the slave, I would be very grateful if you could test it in your setup as well. You'll need to use the experimental update site ( http://updates.jenkins-ci.org/experimental/update-center.json ) configured in the Advanced tab of the Plugin manager, the released version is 1.0.9-beta-2. Zoran

          Jonathan Rogers added a comment - - edited

          I was able to install 1.0.9-beta-2 manually and it works exactly as you describe. Thanks for the quick fix. BTW, I doubt it's specific to this plugin, but I have not yet been able to force Jenkins to update its plugin list. I changed the update URL to the experimental one, but neither clicking the "Check Now" button nor restarting Jenkins caused it to see Xvfb 1.0.9-beta-2. Jenkins definitely updates the list itself periodically but having to wait some unknown amount of time after changing the URL isn't very practical. Do you have any idea why it behaves like this?

          Jonathan Rogers added a comment - - edited I was able to install 1.0.9-beta-2 manually and it works exactly as you describe. Thanks for the quick fix. BTW, I doubt it's specific to this plugin, but I have not yet been able to force Jenkins to update its plugin list. I changed the update URL to the experimental one, but neither clicking the "Check Now" button nor restarting Jenkins caused it to see Xvfb 1.0.9-beta-2. Jenkins definitely updates the list itself periodically but having to wait some unknown amount of time after changing the URL isn't very practical. Do you have any idea why it behaves like this?

          zregvart added a comment -

          Fixed in 1.0.9

          zregvart added a comment - Fixed in 1.0.9

            zregvart zregvart
            jrogers Jonathan Rogers
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: