|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The setup you have should generate unique display numbers, the only way that I see you getting the error that you're getting is if the Xvfb was not terminated when the job finished, i.e. if the Jenkins itself crashes. So the display number would be still occupied by the 'zombie' Xvfb process started by the Xvfb plugin that did not terminate due to the Jenkins crash.
In that case from version 1.0.9 (
JENKINS-20758) and further in version 1.0.10 (https://github.com/jenkinsci/xvfb-plugin/commit/cd3b4b0280c2754782a2d23248665830192441fb) there is support in the Xvfb plugin to try and shutdown previously started, but not terminated Xvfb processes when master starts or slave reconnects.The management of the lock files is done by Xvfb process itself, I doubt that the running process would remove it's own lock file and keep running.
The 'Shutdown Xvfb with whole job, not just with the main build action' option lets you keep Xvfb running until the job completely finishes, i.e. if you need it running in post build actions, not just for the main build actions, so it probably is not very helpful in your case.
To quickly fix your problem you could use the 'Let Xvfb choose display name' option, when used Xvfb picks its own display name by looking for an unused port.
But if you to troubleshoot this further, you need to check if there are dangling Xvfb processes left when the job finishes and try to narrow down the circumstances under which Xvfb fails to start with "SocketCreateListener() failed" message.