I am seeing the same problem “Applying retention policies” never finishes, in version 3.2.1 But the reason is different. Log says it’s due to not being able to delete the files.
Should this perhaps just error out with this explanation? Or is there a setting our Octoadmins can configure to reduce the retry count and error out earlier.
a.txt (5 KB)
Hi Jaon,
Looking at the log you have provided It appears as though the process is having trouble trying to remove the directory E:\Octopus\Applications\TPCH-D430 (Server 2012 IIS)\FreqEd.Service\2.2016.1129.3_1. Is there some process (I’m guessing IIS) that perhaps still has a lock on these files? In your deployment process does it keep creating new IIS websites, leaving the old one running (which in this case means that one of the folders that Octopus thinks it can clean up is still being used). If you check IIS are there any websites still using this folder?
Let me know what you find.
Cheers,
Rob
Hi Rob,
Yes on occasion our deployed windows service will hang when stopping.
For each deployment, a new folder with the version number as part of its
name is deployed, and the IIS site is remapped to the new folder, the
windows service is also remapped to the new location (the prior deployed
windows service exe is stopped)
We are aware of the hangs, my comment, was more specifically about not
knowing (directly unless quizzing the logs) the reason for why Ocotopus was
’hanging’ on applying retention policies. If this is expected behaviour
then that is fine. It wasn’t initially obvious that there was a error
occuring (locked files) from the UI.
Cheers,
Jason
Hi Jason,
From the logs on the server side what are you seeing when this is occurring? I would expect to see those same “retry” lines showing if you click “verbose”. Unfortunately the retry mechanism isn’t something that is currently configurable. The assumption is that if this isnt working correctly then there is probably an underlying issue at play (in this case as you have identified, hanging processes) which when looking at the logs, should be and identified and fixed. This then will mean the long retention policy will go away.
We are always open to suggestions for feature requests so if you feel that this is a change that others may benifit from please add your thoughts to our uservioice area. We can then guage how much impact this will have on users as a whole, and prioritise accordingly.
I’m sorry that this might not be the answer you were initially hoping for. Let me know if i can be of further assistance or would like more clarification on this issue.
Rob