We had a patching window this past weekend and I noticed that beginning Sunday morning, the Timer Service Recycle job was failing. Its scheduled to run at the default 6:00 am and has failed every day since. The error that accompanies the failed job is that the recycle couldnt run due to a running instance of the Microsoft SharePoint Foundation Usage Data Import (see below).
The Execute method of job definition Microsoft.SharePoint.Administration.SPTimerRecycleJobDefinition (ID 20fea14e-75db-4e86-a1af-d780fd87eb01) threw an exception. More information is included below.
The timer service was not recycled because the following jobs were still running: Microsoft SharePoint Foundation Usage Data Import
Ive since observed the Usage Data Import job and noticed that its taking unusually long to run. Checking the ULS, the following jumped out at me:
Deleting usage log file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\***-*******-20130502-1600.usage' after data import.
Failed to delete usage log file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\***-*******-20130502-1600.usage' after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileInfo.MoveTo(String destFileName)
at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath)
at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi)
at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)
It appears that file is marked for deletion but then fails as the file is locked by another process. I enabled verbose logging but didnt see anything beyond the above error. I even tried to manually delete one of the usage files while the job was running and it appears to be locked up by the SharePoint timer. Also thought that this may be related to the patching that was done and uninstalled all patches from test but the problem still exists.
My other thought was that perhaps some real-time virus scanning was locking the folders. However, McAfee is not installed in my test environment so I know this also isn't the issue.
Any thoughts or suggestions would be greatly appreciated.