Hello,

I'm getting warning for SPTimerV4 service is failing to recycle. It fails on all SP Servers.

"The timer service was not recycled because the following jobs were still running: Microsoft SharePoint Foundation Usage Data Import"

How can I fix this issue?

I also get the following message in ULS Logs as well. I'm not sure if they are related!

Failed to delete usage log file 'H:\SharePoint Logs\xxxx.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)

Thanks

It'll be down to scheduling, that job can take a while and the recycle job has a 15 minute timeout. Move the Usage schedule to half an hour after the recycle job is scheduled for.

They are already scheduled for different times.

So, currently recycle job starts at 6am, and usage data processing scheduled to 1am, and usage data import runs every 30 minutes.

Good point,

Are there any errors in the ULS logs for the usage import? They can cause long running usage imports and result in this situation.

http://social.technet.microsoft.com/Forums/sharepoint/en-US/e8af5657-7ca4-4ae7-bbe8-9609bb341ca8/usage-data-import-job?forum=sharepointgeneralprevious

• Marked as answer by John_35 Monday, November 25, 2013 3:21 PM

Please stop all the  jobs that are running, using PowerShell to do that

http://buttongo.de/PS_Windows/en/Stop-Job.htm

Then recycle timer service again.

Regards,

Jayant

Alex,

I already checked that thread, and I could not find that Windows KB installed. I have the same ULS Log the other post has. I will post it here in a few minutes.

Jayant,

I also saw that site, but I worried to do it. Do you think it is safe to do it?

Thanks all.

In my case, I have KB2882822.
However what I noticed was that the WSS_ADMIN_WPG should have had Full Control permission on Hive 14/LOGS and it doesn't ( it inherits modify from the parent )
Then WSS_WPG should have had Modify permission on Hive 14/LOGS and it doesn't go beyond Read/Write.
On the latter, it sits LOCAL SERVICE which is the account run by the tracelogs.

http://technet.microsoft.com/en-us/library/cc678863%28v=office.14%29.aspx

So, missing out on what KB from Microsoft had caused the issue, I repositioned the permissions back as they should. It seems to fix this issue.

Uninstalling KB2882822 fixed the issue!

Thanks all

In my case, I have KB2882822.
However what I noticed was that the WSS_ADMIN_WPG should have had Full Control permission on Hive 14/LOGS and it doesn't ( it inherits modify from the parent )
Then WSS_WPG should have had Modify permission on Hive 14/LOGS and it doesn't go beyond Read/Write.
On the latter, it sits LOCAL SERVICE which is the account run by the tracelogs.

http://technet.microsoft.com/en-us/library/cc678863%28v=office.14%29.aspx

So, missing out on what KB from Microsoft had caused the issue, I repositioned the permissions back as they should. It seems to fix this issue.

I added modify permissions to WSS_ADMIN_WPG to the hive14/logs for the fix, I didn't have KB2882822 though.  Thanks for pointing that out Nuno Aragao.

Hi Colin.

Also KB268011 and KB2775511 caused impacts on the correct management of log files.
According to the technote, the Cumulative Update of December 2013 fixed these issues.