Closed Tech356 closed 6 years ago
Running Ohai with log level set to debug shows that the dism command is timing out.
C:\Users\user>ohai -l debug -d c:/chef/ohai/plugins dism_features
...
DEBUG: Loading plugin at c:/Chef/ohai/plugins/dism_features.rb
DEBUG: Plugin DismFeatures: ran 'C:\Windows\sysnative\dism.exe /Get-Features /Online /Format:Table' and timed out after 30 seconds
DEBUG: Plugin DismFeatures threw #<Ohai::Exceptions::Exec: command timed out:
---- Begin output of C:\Windows\sysnative\dism.exe /Get-Features /Online /Format:Table ----
STDOUT: Deployment Image Servicing and Management tool
Version: 6.1.7600.16385
Image Version: 6.1.7600.16385
STDERR:
---- End output of C:\Windows\sysnative\dism.exe /Get-Features /Online /Format:Table ----
ProcessId: 5056
app_name: C:\Windows\sysnative\dism.exe
command_line: C:\Windows\sysnative\dism.exe /Get-Features /Online /Format:Tabletimeout: 30>
...
Subsequent runs of dism return within the timeout.
C:\Users\user>ohai -l debug -d c:/chef/ohai/plugins dism_features
...
DEBUG: Loading plugin at c:/Chef/ohai/plugins/dism_features.rb
DEBUG: Plugin DismFeatures: ran 'C:\Windows\sysnative\dism.exe /Get-Features /Online /Format:Table' and returned 0
{
"OEMHelpCustomization": "Disabled",
"CorporationHelpCustomization": "Disabled",
"SimpleTCP": "Disabled",
...
}
After every reboot, dism would timeout the first time. Timing the runs using a stopwatch gave 57.69 seconds for the first invocation and 16.91 seconds for the second invocation.
PR #402 removed the WMI query that was used on Win7+ machines. Adding it back into the plugin would presumably fix this issue.
# Win32_OptionalFeature wmi class is only available in Win7+ (NT >= 6.1), but is way faster than dism.exe
if win_version.major_version > 6 || (win_version.major_version == 6 && win_version.minor_version >= 1)
!execute_wmi_query("SELECT * FROM Win32_OptionalFeature WHERE Name='#{@new_resource.feature_name}' AND InstallState=1").nil?
else
cmd = shell_out("#{dism} /online /Get-Features", returns: [0, 42, 127])
cmd.stderr.empty? && (cmd.stdout =~ /^Feature Name : #{@new_resource.feature_name}.?$\n^State : Enabled.?$/i)
end
Can you reproduce this issue on windows cookbook version 3?
I have not deployed version 3 yet. The code doesn't look to change between versions so I would expect similar results.
There was just a PR merged that should fix the idempotency of the feature
For reference, the PR that was merged is #495 and was released in 3.2.0.
Cookbook version
2.1.1
Chef-client version
12.19.36
Platform Details
Windows 7 x64
The same code worked in v2.0.2. The bug seems to have been introduced in https://github.com/chef-cookbooks/windows/pull/402 but I cannot find the specific bug. It seems that the
dism_features
is not loading initially (but still creating an empty Mash) which causes the firstwindows_feature
resource to re-install. Then on the ohai reload it is loading all the features. I have not been able to find what is causing this behavior.Scenario:
Here is the recipe
Here is the log
To troubleshoot this problem I added additional logging to the
installed?
functionAfter adding the additional logging, the log looks like this
For each subsequent
windows_feature
, the resource correctly identifies the feature as already installed.When I run the ohai command manually it returns no results
The plugin path is included in the
client.rb
config