I had an issue with Octopus running out of disk space and traced it to the size of the Package Cache. I noticed that the age of packages in the cache were continuous from server install to the present. Finding another issue around the cache (http://help.octopusdeploy.com/discussions/problems/40402-package-cache-is-full) I applied the configuration change (updating to retain 1 day) to see if that would ‘kick-start’ the retention process. After several days I have come back to check and it appears nothing has been removed from PackageCache.
I will now create a local server process to clean these up out of band but this seems (?) to be a bug in the current implementation. I do not see mention of it in the release notes up to 3.2.13 so assume this issue still exists.
I would include the log but at the ‘Info’ level I see no mention of retention tasks. I have now turned up the logging to ‘Debug’ to gather additional data. As a side note, the instructions on the wiki for v3+ at (http://docs.octopusdeploy.com/display/OD/Log+files) indicating set the log in NLog.config now appear to be out of date as I found the configuration in octopus.server.exe.nlog.
Thanks for getting in touch. It’s strange that it’s not removing the packages. Can I confirm that you restarted the OctopusDeploy service after executing the configure command? The service needs to be restarted to take effect. Once this is done, a server task is scheduled to run after thirty minutes and then every four hours after that. This task removes files based on the following rules and tries to delete the files three times in case they are temporarily locked.
Last write timestamp has to be older than the cache packages number of days
Last access time has to be greater than 3 hours
If your server is used heavily, then the package cache can stay somewhat large. Cleaning it manually or out-of-band will work but it should do it automatically.
Lastly, thanks for pointing out the logging documentation issue. I’ve created a task to fix that up.
Apologies for this thread getting a little stale…just getting back to this after the holidays. We are still not seeing the expected automatic application of retention to package cache.
I turned off the out of band package cache deletion so my oldest files in package cache are dated 15 December 2015.
I did a fresh reconfiguration command with administrator privs using octopus.server.exe configure --cachePackages=2 to set retention to 2 days. I also set the logging level to ‘debug’ and restarted the Octopus service.
Restart was performed at about 11:45AM local time (US Central) today (Friday, 08 Jan). I do not see any log or task activity around clearing package cache and, indeed, the ‘expired’ files remain in the package cache.
I have included the system report, the latest log file (including restart + 1.5 hours activity beyond), and a screenshot of the cache directory with file access/modification time where I would have expected files to be deleted thru 48 hours ago.
I am not sure if it matters but to ensure the information is included…Octopus service runs under a custom domain account.
Thanks for following-up and sending through the detail logs and screenshot. The issue is that our current package cache cleaner is leaving behind package delta artifacts and this is what’s left in the package cache directory. We recently had this same issue reported and we have created a github issue to get it fixed. You can follow it’s progress at the following URL. https://github.com/OctopusDeploy/Issues/issues/2279
.