Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added fix for thread error #341

Closed
wants to merge 1 commit into from
Closed

Added fix for thread error #341

wants to merge 1 commit into from

Conversation

nikhil2611
Copy link

Fixed the below thread error coming up on windows nodes on the execution of the kitchen verify and knife commands.

Test Summary: 0 successful, 0 failures, 1 skipped Finished verifying <default-windows-2022-base1> (0m18.89s). -----> Test Kitchen is finished. (0m35.20s) /opt/chef-workstation/bin/kitchen: warning: Exception in finalizer #<Proc:0x000000011bf58a18 /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/winrm-2.3.6/lib/winrm/shells/power_shell.rb:33> /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:471:in new': can't alloc thread (ThreadError)
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:471:in create_with_logging_context' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:436:in new'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/timeout-0.3.2/lib/timeout.rb:101:in create_timeout_thread' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/timeout-0.3.2/lib/timeout.rb:134:in block in ensure_timeout_thread_created'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/timeout-0.3.2/lib/timeout.rb:132:in synchronize' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/timeout-0.3.2/lib/timeout.rb:132:in ensure_timeout_thread_created'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/timeout-0.3.2/lib/timeout.rb:181:in timeout' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:515:in query'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient/session.rb:177:in query' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:1242:in do_get_block'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:1019:in block in do_request' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:1133:in protect_keep_alive_disconnected'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:1014:in do_request' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:856:in request'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/httpclient-2.8.3/lib/httpclient.rb:765:in post' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/winrm-2.3.6/lib/winrm/http/transport.rb:176:in send_request'
from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/winrm-2.3.6/lib/winrm/shells/power_shell.rb:42:in close_shell' from /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/winrm-2.3.6/lib/winrm/shells/power_shell.rb:33:in block in finalize'`

Issue - chef/chef-workstation#3073

Signed-off-by: nikhil2611 <nikhilgupta2102@gmail.com>
@@ -34,12 +34,16 @@ def finalize(connection_opts, transport, shell_id)
end

def close_shell(connection_opts, transport, shell_id)
return false unless Thread.current.alive?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, if Thread.current is not alive, how could this code be executing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thread is generally in asleep in my testing results. If it’s dead, I don’t think there’s much recourse that won’t potentially cause additional side effects. Maybe we rescue instead of returning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It strikes me as super odd that the thread would be sleeping if the code is actually running. In your testing, are you examining the thread status of Thread.current or are you observing the thread's status from a different thread.

msg = WinRM::WSMV::CloseShell.new(
connection_opts,
shell_id: shell_id,
shell_uri: WinRM::WSMV::Header::RESOURCE_URI_POWERSHELL
)
transport.send_request(msg.build)
rescue ThreadError => e
logger.debug("#{e.message}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern is that this just masks an error that should probably be raised. The underlying transport is still unable to close the shell which could result in orphaned powershell processes on the remote.

@mwrock
Copy link
Member

mwrock commented Dec 7, 2023

Closing since this does not truly "fix" the root of the problem. A solution like this is likely best implemented in the upstream application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants