Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Not A Defect
-
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
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
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.
Also experiencing this issue.
Things to know:
Restarting Jenkins (and consequently the plugin) tends to fix this issue. Restarting the server is not required.