Workspace cleanup failing after updating Jenkins 2.65

[t3knoid]

I recently updated to Jenkins 2.65 and some of my plugins. Now every time I try to build a job that has been working all along, the job fails when trying to clean the workspace. It only happens after every other job. I can get around the issue by restarting the slave service (Windows). This is obviously not a solution. How can I go about checking what is causing the lock on the folder?

[Mark Waite]

Interesting that it only happens every other job.

You might consider https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows as a starting point to confirm that the process locking the file (or directory) is java.exe that is running Jenkins.  If it is not, then whatever process is holding the lock is the one you'll need to stop at the end of the job.

If the lock is held by the java.exe which is running Jenkins, then I think you'll need to bisect the changes from what was working previously to now, so that you can identify the plugin (or core) that introduced the change.  Once you've isolated it, then report a bug on that component.

Mark Waite 

On Wed, Jun 21, 2017 at 11:57 AM t3knoid <t3k...@gmail.com> wrote:

I recently updated to Jenkins 2.65 and some of my plugins. Now every time I try to build a job that has been working all along, the job fails when trying to clean the workspace. It only happens after every other job. I can get around the issue by restarting the slave service (Windows). This is obviously not a solution. How can I go about checking what is causing the lock on the folder?

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ed2ab916-7923-4355-9b3f-2e625de0d360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francis Refol]

It's definitely java.exe. I see a hold on that folder using a utility called handle.exe from Sysinternals. I am troubleshooting now. I am getting around the problem by not using "Delete workspace before build starts" option and setting my Subversion setting to "Always check out a fresh copy." This essentially is the same as deleting the workspace. The odd thing is that the hold is only on the folder and not the files that are in the folder. That's why the "Delete workspace before build starts fails" because it also tries to remove the job's workspace folder.

On Wed, Jun 21, 2017 at 3:04 PM, Mark Waite <mark.ea...@gmail.com> wrote:

Interesting that it only happens every other job.

You might consider https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows as a starting point to confirm that the process locking the file (or directory) is java.exe that is running Jenkins.  If it is not, then whatever process is holding the lock is the one you'll need to stop at the end of the job.

If the lock is held by the java.exe which is running Jenkins, then I think you'll need to bisect the changes from what was working previously to now, so that you can identify the plugin (or core) that introduced the change.  Once you've isolated it, then report a bug on that component.

Mark Waite 

On Wed, Jun 21, 2017 at 11:57 AM t3knoid <t3k...@gmail.com> wrote:

I recently updated to Jenkins 2.65 and some of my plugins. Now every time I try to build a job that has been working all along, the job fails when trying to clean the workspace. It only happens after every other job. I can get around the issue by restarting the slave service (Windows). This is obviously not a solution. How can I go about checking what is causing the lock on the folder?

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ed2ab916-7923-4355-9b3f-2e625de0d360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/RCbxvLaN_ls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHiAz%3DHf5P%3DAbG8P%2BZZvj7sGMU9pKSyPJ2%3DBa8%3DVMU2hA%40mail.gmail.com.

[t3knoid]

I have another job that uses the same option and is working just fine. The one that is failing is a Java application using Maven to build.

[t3knoid]

I narrowed down the java.exe process that is holding the folder open. Here's the command:

"C:\Program Files\Java\jdk1.7.0_80\bin\java" -cp c:\jenkins\maven35-agent.jar;C:\apache-maven-3.5.0\boot\plexus-classworlds-2.5.2.jar;C:\apache-maven-3.5.0/conf/logging jenkins.maven3.agent.Maven35Main C:\apache-maven-3.5.0 C:\jenkins\slave.jar c:\jenkins\maven35-interceptor.jar c:\jenkins\maven3-interceptor-commons.jar 1942

Interestingly enough, Jenkins runs under Java 1.8. The maven job is using 1.7. Not sure if this is relevant. Anyway, does anyone know what triggers the above command?

[Stephen Connolly]

Isn't Jenkins 2.65 Java 8 required (which will push the same onto the evil job type)?

--

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b80620f4-9ae1-42c4-bdaf-8d4cd517fd00%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent from my phone

[t3knoid]

Yes. According to Maven plugin doc, it will force use of 1.8 to perform the compile.

https://wiki.jenkins-ci.org/display/JENKINS/Maven+Project+Plugin

I'm wondering why 1.7 is being used in the command I referenced.