-
Bug
-
Resolution: Not A Defect
-
Minor
-
None
-
Jenkins: 1.651.2
Xvfb Plugin: 1.1.3
Docker Image of Jenkins: https://hub.docker.com/r/silintl/appbuilder-jenkins/
Docker Image of Slave: https://hub.docker.com/r/silintl/appbuilder-agent/ (tag: nozombies, base: https://hub.docker.com/r/phusion/baseimage/)
Docker Host: Ubuntu 14.04
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?
[JENKINS-35102] Xvfb is not stopped
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
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?
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.
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. 
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.
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. 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.
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
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.
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.
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.