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

When chef-client is run via knife ssh, then we are not being informed about the resource that is executed at present #8778

grdz opened this issue Jul 26, 2019 · 1 comment


Copy link

commented Jul 26, 2019


When we run chef-client while being logged into the node, then we could see the name of the resource that is being executed, and action that is being performed ("action run" for example):

  * execute[sleep-for-60-seconds] action run

and then when it has been executed, we could see a new line, usually green, saying that the resource has actually been executed:

  * execute[sleep-for-60-seconds] action run
    - execute sleep 60s

But when we run chef-client using knife ssh, then we do not see the first line saying that the resource is being executed right now. We only get it along with the second line, after the resource has been finished executing.

Chef Version


Platform Version

CentOS 7.6

Replication Case

Just set resource like this:

execute 'sleep-for-60-seconds' do
  command 'sleep 60s'
  action :run

and run it on a node via knife ssh like this:

knife ssh '' --ssh-user root -i ~/.ssh/id_rsa 'chef-client' --attribute ipaddress

You will see that you will not get line saying that this resource is being executed. You don't know what resource is being executed right now, without looking at the recipe code. But while executing chef-client directly on a node, you will first see information that resource execution started, and then after 60 seconds a green line saying that it finished executing, so you know what is being executed right now. Both workstation where knife ssh is being executed, and a node, have log_level :info set.

Client Output

Just as described above


There is no stacktrace available


This comment has been minimized.

Copy link

commented Jul 26, 2019

Ultimately this comes down to ssh's buffering, but there's no way to force pty allocation from knife ssh to Net::SSH and it doesn't look like knife ssh supports arbitrary session options Net::SSH. It would be solvable in .ssh/config, but Net::SSH doesn't know how to parse the RequestTTY option. more fuel for inspec/train#30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.