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

Xvfb is not stopped

    XMLWordPrintable

Details

    Description

      I have "Start Xvfb before the build, and shut it down after." enabled.
      Without "Let Xvfb choose display name" enabled, the first execution of a job would run and leave Xvfb running so that the next execution of the build (within a few minutes) would fail:

      Xvfb starting$ Xvfb :1 -screen 0 1024x768x24 -fbdir /xvfb-15-243204126288424340.fbdir
      (EE)
      Fatal server error:
      (EE) Server is already active for display 1
      If this server is no longer running, remove /tmp/.X1-lock
      and start again.
      (EE)
      unlink: No such file or directory
      unlink failed, Invalid argument
      ERROR: Xvfb failed to start, consult the lines above for errors
      Archiving artifacts
      Build did not succeed and the project is configured to only push after a successful build, so no pushing will occur.
      Finished: FAILURE

      Running "ps ax" on the slave would show the process running.

      If I happen to wait a few minutes (not sure how many), then it will not fail, but only the previous Xvfb process is running (a new one is not started).

      Someone suggested me turning on "Let Xvfb choose display name". Now a new process is started for each build and left running (and accumulating).

      I also tried enabling "Shutdown Xvfb with whole job, not just with the main build action" and that didn't help.

      I enabled "Log Xvfb output", but I don't see any extra logging at shutdown. Is there a way to diagnose why Xvfb is not stopping? System logs to look at?

      Attachments

        Activity

          chris_hubbard Chris Hubbard created issue -
          chris_hubbard Chris Hubbard added a comment -

          Since I can guarantee that there is only one build happening at a time on a slave, I guess I can add "killall Xvfb" at the end of my main build script to make sure the process gets killed. I don't know why the plugin is not killing it.

          chris_hubbard Chris Hubbard added a comment - Since I can guarantee that there is only one build happening at a time on a slave, I guess I can add "killall Xvfb" at the end of my main build script to make sure the process gets killed. I don't know why the plugin is not killing it.
          zregvart zregvart added a comment -

          Hi Chris thanks for reporting the issue, can you provide more detail on how to reproduce the issue:

          • are you running agents on same physical machine in separate containers?
          • is the build tied to one of the agents?
          • do you have multiple jobs run in parallel?
          • what kind of build job are you using (freestyle, maven, matrix, pipeline,...)?
          • any details about the job I should be aware of?
          zregvart zregvart added a comment - Hi Chris thanks for reporting the issue, can you provide more detail on how to reproduce the issue: are you running agents on same physical machine in separate containers? is the build tied to one of the agents? do you have multiple jobs run in parallel? what kind of build job are you using (freestyle, maven, matrix, pipeline,...)? any details about the job I should be aware of?

          Same here. If a run the same job in a row, the job often fails. If I retry later, it works. Free-style job. Only one physical machine. No jobs in parallel.

          rvcoutinho Rômulo Coutinho added a comment - Same here. If a run the same job in a row, the job often fails. If I retry later, it works. Free-style job. Only one physical machine. No jobs in parallel.
          starpit Nick Mitchell added a comment -

          We have also begun to see this problem. We are running 1.0.16. It seems that, when a (freestyle, for us) job fails, Xvfb sometimes does not get cleaned up properly. We're running one slave per SoftLayer VM, no parallelism on node, but multiple jobs running across nodes.

          starpit Nick Mitchell added a comment - We have also begun to see this problem. We are running 1.0.16. It seems that, when a (freestyle, for us) job fails, Xvfb sometimes does not get cleaned up properly. We're running one slave per SoftLayer VM, no parallelism on node, but multiple jobs running across nodes.
          rtyler R. Tyler Croy made changes -
          Field Original Value New Value
          Workflow JNJira [ 171321 ] JNJira + In-Review [ 184256 ]
          chrisagiddings Chris Giddings added a comment - - edited

          Also experiencing this issue.

          • Jenkins master only, no slaves
          • No parallelism
          • Maven job

          Things to know:

          • Jenkins 2.51
          • Xvfb plugin 1.1.3
          • Ubuntu Linux

          Restarting Jenkins (and consequently the plugin) tends to fix this issue. Restarting the server is not required.

          chrisagiddings Chris Giddings added a comment - - edited Also experiencing this issue. Jenkins master only, no slaves No parallelism Maven job Things to know: Jenkins 2.51 Xvfb plugin 1.1.3 Ubuntu Linux Restarting Jenkins (and consequently the plugin) tends to fix this issue. Restarting the server is not required.

          Bumping.

          This issue happens to us a couple times a week at this point with only one Jenkins job even using this plugin.

          chrisagiddings Chris Giddings added a comment - Bumping. This issue happens to us a couple times a week at this point with only one Jenkins job even using this plugin.
          zregvart zregvart added a comment -

          chrisagiddings, starpit, rvcoutinho, any description on how to reproduce this would help solve this, without that it is very difficult to find a solution.

          Can you provide steps that provoke the issue? Could you provide debug logs from the job run? Could you provide job configurations?

          If you have the means, could you launch a debug session and see if the execution reaches shutdownAndCleanup method.

          Could it be that this is something relating to the version of Xvfb? Try to running Xvfb within your environment with -displayfd 2 option and see if you get different display numbers.

          Do note that this is an open source project that anyone can contribute to and it is done mainly by volunteers in their spare time, so if you can think of a solution pull request would be very welcome.

          zregvart zregvart added a comment - chrisagiddings , starpit , rvcoutinho , any description on how to reproduce this would help solve this, without that it is very difficult to find a solution. Can you provide steps that provoke the issue? Could you provide debug logs from the job run? Could you provide job configurations? If you have the means, could you launch a debug session and see if the execution reaches shutdownAndCleanup method. Could it be that this is something relating to the version of Xvfb? Try to running Xvfb within your environment with -displayfd 2 option and see if you get different display numbers. Do note that this is an open source project that anyone can contribute to and it is done mainly by volunteers in their spare time, so if you can think of a solution pull request would be very welcome.

          @zregvart I will see what I can do with some upcoming builds and let you know. A lot of what we deal with is protected data, so I may have to find a way to redact details.

          We're adding a second job now which uses this plugin.

           

          Thanks for the followup.

          chrisagiddings Chris Giddings added a comment - @ zregvart  I will see what I can do with some upcoming builds and let you know. A lot of what we deal with is protected data, so I may have to find a way to redact details. We're adding a second job now which uses this plugin.   Thanks for the followup.

          As it turns out, someone else had been fudging with the display offsets and set them to zero.

          After setting the display offsets to different (non-zero) values we have not encountered this issue.

          chrisagiddings Chris Giddings added a comment - As it turns out, someone else had been fudging with the display offsets and set them to zero. After setting the display offsets to different (non-zero) values we have not encountered this issue.
          zregvart zregvart made changes -
          Resolution Not A Defect [ 7 ]
          Status Open [ 1 ] Fixed but Unreleased [ 10203 ]
          zregvart zregvart made changes -
          Status Fixed but Unreleased [ 10203 ] Closed [ 6 ]

          People

            zregvart zregvart
            chris_hubbard Chris Hubbard
            Votes:
            4 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: