I see this as a bug or feature request for jenkins.
As an end user of the jenkins web application, I am not trying to delete a file.
I am merely trying to install a plugin. The code within Jenkins which manages
plugin installation should be able to run gracefully (by not failing and
throwing a stack trace) when run on an NFS file system.
Regards,
Peter
On 5/23/12 4:20 PM, Vojtech Juranek wrote:
Hi,
this is not a bug in Jenkins. It's due to how NFS works and it means that you
are trying to delete
a file which is still open by some process. For short explanation see e.g. [1].
Cheers
Vojta
[1] https://uisapp2.iu.edu/confluence-prd/pages/viewpage.action?pageId=123962105
On Wednesday 23 May 2012 21:31:39 John Vacz wrote:
I also encountered the same error after migrating our Jenkins to a new
system with NAS storage. Updating plugins becomes quite annoying The
error also occured occasionaly when Jenkins trying to delete the old
builds. Because of the IOException2 caused by some mysterious
.nfs000000000 files, Jenkins fails to remove the build on left side
menu, although the build directories dissapears shortly after.
If the NAS is really the culprit, I would rather consider this as an
avoidable problem: simply do not use NFS as Jenkins home or slave root
fs. As we see all data generated by Jenkins as dispensable,as long as
the configurations are archived, recover from disk failure is not a big
deal. But our (paranoid) admins (generously) provided us such NAS system
with all kinds of journaling/versioning/backup features, which we
couldn't care less. I'm still trying to persuade them to gave us some
normal "low-level" storage instead.
Anyways Im also interested in the same question, or any
configurations/tricks/workarounds to avoid this, for the time being or
if we must live with NAS.
On 22.05.2012 22:56, Peter Carr wrote:
I noticed the included error stacktrace on the Update Center tab, for
my Git Plugin. It is caused, I think, because I am running Jenkins on
a VM with NFS storage. Occasionally, the temporary .nfs* files show up
while doing an 'ls', but then they disappear a little bit later. In
implementing similar systems, I have developed the habit of ignoring
all '.nfs*' files when doing directory listings. Is it possible this
is an error in the core of Hudson?
Here is the stack trace:
hudson.util.IOException2: Failed to dynamically deploy this plugin
at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:
1138)
at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:956)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Unable to delete /xchip/gpint/tools/
hudson/plugins/github/WEB-INF/lib/.nfs00000000001b3cc400000ba3
at hudson.Util.deleteFile(Util.java:237)
at hudson.Util.deleteRecursive(Util.java:287)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.Util.deleteRecursive(Util.java:286)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.Util.deleteRecursive(Util.java:278)
at hudson.Util.deleteContentsRecursive(Util.java:198)
at hudson.Util.deleteRecursive(Util.java:278)
at hudson.ClassicPluginStrategy.explode(ClassicPluginStrategy.java:
389)
at
hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.jav
a: 113)
at hudson.PluginManager.dynamicLoad(PluginManager.java:352)
at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:
1134)
... 7 more
