-
Bug
-
Resolution: Won't Do
-
Minor
-
None
-
Ubuntu 14.04
We were getting the following intermittent error on our builds:
FATAL: /var/lib/jenkins/xvfb-157-8380869945976165128.fbdir/.nfs00000000000ad5a20004f107: Device or resource busy
java.nio.file.FileSystemException: /var/lib/jenkins/xvfb-157-8380869945976165128.fbdir/.nfs00000000000ad5a20004f107: Device or resource busy
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
In order to address this, I started passing the following flag: "-fbdir /tmp"
See attached screen shot.
The error seems to have gone away, but in the console log, I see that the -fbdir flag is being passed twice. Does Xvfb ignore the first -fbdir parameter and only read the 2nd one?
Here is the new message in the console log:
Xvfb starting$ /usr/bin//Xvfb -displayfd 2 -screen 0 1024x768x24 -fbdir /var/lib/jenkins/xvfb-381-8251290578769946893.fbdir -fbdir /tmp
[JENKINS-34066] Xvfb plugin is passing in -fbdir twice
zregvart
added a comment - Decided that leaving `fbdir` up to user is not a good idea. 
M Chon
added a comment - This will break our environment again, because we host JENKINS_HOME on a NetApp partition (/var/lib/jenkins). So unless the Xvfb plugin is hardcoding TMP to point to /tmp and not somewhere under JENKINS_HOME , we will start getting these /.nfs00000000000ad5a20004f107: Device or resource busy errors again. It was working before, can you revert it?
M Chon
added a comment - This will break our environment again, because we host JENKINS_HOME on a NetApp partition (/var/lib/jenkins). So unless the Xvfb plugin is hardcoding TMP to point to /tmp and not somewhere under JENKINS_HOME , we will start getting these /.nfs00000000000ad5a20004f107: Device or resource busy errors again. It was working before, can you revert it? zregvart
added a comment - As of JENKINS-36355 frame buffer directory is not within the node's temporary location, but within workspace.
zregvart
added a comment - As of JENKINS-36355 frame buffer directory is not within the node's temporary location, but within workspace. M Chon
added a comment - This is potentially an issue for us because our workspaces are hosted on a network share, not a hard drive. This will potentially lead to the plugin becoming unusable for us, because it will throw nfs errors due to forcing the tmp area to be located in the workspace, which for us is an NFS drive.
All I was asking when I filed this bug for was clarification, not for the behavior of the plugin to be changed.
Can it please be changed back?
M Chon
added a comment - This is potentially an issue for us because our workspaces are hosted on a network share, not a hard drive. This will potentially lead to the plugin becoming unusable for us, because it will throw nfs errors due to forcing the tmp area to be located in the workspace, which for us is an NFS drive.
All I was asking when I filed this bug for was clarification, not for the behavior of the plugin to be changed.
Can it please be changed back? 
By looking at the Xorg source xserver/tree/hw/vfb/InitOutput.c:365 you can see that the last fbdir argument takes precedence. I would strongly suggest that you leave the management of fbdir argument to the Xvfb Jenkins plugin and see if you can fix the underlaying OS problem (Device or resource busy). Setting the fbdir to a non unique directory will fail your build as the Xvfb would not be able to run if the job is run in parallel with (another or same) job that uses the same fbdir directory.
If you absolutely need to specify your own fbdir directory and take it upon yourself to maintain the uniqueness of it across all your builds I could modify the Jenkins Xvfb plugin to use the specified instead of the temporary directory unique to each run.