windows_feature msi guard causes memory leak

[jonathanmorley]

On Windows 2008 R2, running the following powershell causes the TrustedInstaller service to jump from a 1.8Mb baseline to 85Mb used (and doesn't come back down).

Get-WmiObject -Query "SELECT * FROM Win32_OptionalFeature"

Each subsequent use of this command causes a 100 - 300Mb increase in TrustedInstaller's RAM usage

The following command also causes TrustedInstaller to jump to around 85Mb, but it immediately settles back down to a stable 8Mb

dism /online /get-features

These are the commands run by the guard of windows_feature as of #257.

While the new guards are faster, we have seen trustedInstaller services grow to over 1Gb of RAM usage, since the guards are executed every time chef runs.

We need some better way of determining the installation state of a feature.

[jptoto]

I can confirm this as well. Only on Server 2008 R2. Windows Server 2012 does not seem to be effected. I run Chef-Client as a service (check in every 10 mins) and it was consistently eating all the RAM across several dozen servers until I disabled it.

[smurawski]

I'd consider a PR that would solve this, but most solutions would require caching the state of installed features which could make resources attempt to converge when they should not.

You could also work around that by putting a guard in place that might check an ohai data (which would require a custom plugin) or shell out to query once in the run and check that in your guard.

While I acknowledge there is still a lot of 2008 R2 out there, it's two (and about to be three) major versions back and more current versions do not seem to have this issue. This is really a bug in the Windows 2008 R2 os.

[tas50]

The latest release of this cookbook implemented an Ohai plugin for feature caching. This should work around the leak here by only actually obtaining the state on a change vs. on every call.