Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Unable to create directory #4296

JShelton ·

Using 10.0.21. Recently upgraded our build grid from one that was on 6.0.28. We're seeing an issue, unsure if related to the upgrade (since the issue didn't crop up for many weeks after the upgrade), where a build near instantly fails and we get an error similar to

Unable to create directory: /home/quickbuild/qbartifacts/builds/b658/2658

Most commonly, this occurs in configurations that have been triggered by "Trigger Other Builds" step in other configurations (but we also saw it occur once on a configuration that was manually run via the "run" button). The error always shows itself in the master step and there is no actual log for it. Strangely, we can generally kick off the build again and most of the time it will run again just fine. Another time, it occurred repeatedly on one configuration before clearing itself up and running normally without an issue since.

Our global storage directory (/home/quickbuild/qbartifacts) is writable by the user that is running QB server, though that shouldn't be an issue because it doesn't happen 100% of the time. Server is running on CentOS 7. We have so far been unable to reproduce the error on demand as it seems completely random.

Any ideas on how to address this? Has this sort of error been encountered before in past QB versions?

  • replies 2
  • views 50
  • stars 0
robinshen ADMIN ·
JShelton ·

Unfortunately, upgrade to 10.0.30 has NOT fixed the issue.

I've noticed a pattern here. I've set up a test config that runs every 20 seconds and all that it does is trigger another config that does nothing but execute a groovy script which logs some text. It appears the failures very consistently happen every 2 or 3 hours and, when the failures start, 2 or 3 builds fail at maximum. Essentially, every 2 or 3 hours this failure will be triggered for no more than one minute.

We are using OpenJDK 1.8.0_232.