Chef 15 Infra Client Scheduled Task failing in Windows

Chef Infra (archive)
1

We upgraded our clients to the newly-released Infra Client this week, and it's been fairly smooth for our Linux severs (we had to give them a nudge to accept the license, but no big deal there). The Windows servers have been significantly less happy.

The Scheduled Task that kicks off a chef-client run seems to be silently failing. I've done everything I can to ensure that it's not a licensing issue (C:\chef\client.rb has the chef_license flag set to accept, and I've even tried manually adding "--chef-license accept" to the Scheduled Task's command), and it just refuses to work. I can see a Ruby interpreter launching when I fire off the task manually, but it dies after about 10 seconds. The client doesn't converge, the logs aren't updated, and there's no "Started Chef Infra Client run" entry in the Windows Event Log. Running the task as a non-SYSTEM user does not change the behavior.

So I'm kind of stuck. I managed to get a stacktrace of the failure by redirecting the scheduled tasks's output to a file:

C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/config.rb:24:in `join': no implicit conversion of nil into String (TypeError)
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/config.rb:24:in `default_license_locations'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/config.rb:10:in `initialize'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/acceptor.rb:25:in `new'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/acceptor.rb:25:in `initialize'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/acceptor.rb:95:in `new'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/acceptor.rb:95:in `check_and_persist!'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/chef-15.0.293-universal-mingw32/lib/chef/application.rb:254:in `check_license_acceptance'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/chef-15.0.293-universal-mingw32/lib/chef/application.rb:68:in `run'
	from C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/chef-bin-15.0.293/bin/chef-client:25:in `<top (required)>'
	from C:/opscode/chef/bin/chef-client:167:in `load'
	from C:/opscode/chef/bin/chef-client:167:in `<main>'

When I run the client manually, it works fine. So I'm assuming there's something environment-related going wrong here.

Our scheduled task is created by the chef-client cookbook (latest version from the supermarket), with the following options set by a role:

   "default_attributes": {
     "chef_client": {
       "chef_license": "accept",
       "config": {
         "log_location": "C:/chef/log/client.log",
         "log_level": ":info",
         "chef_license": "accept-silent"
       }
     }

Any ideas?

2

If I were having a problem like that, I would go into:

C:/opscode/chef/embedded/lib/ruby/gems/2.6.0/gems/license-acceptance-1.0.5/lib/license_acceptance/config.rb

3

This should be fixed in license-acceptance 1.0.11

We expect to have a build of Chef out with that in it in the next 24 hours.

4

Thanks for the reply, btm. Because this is running as the SYSTEM user, my guess is that HOMEDRIVE is not set - so it hits the same problem as a Packer-built image in that bug report.

I'll have to run chef-client manually on our Windows servers to let the chef_client_updater cookbook do its thing once that's released, but that shouldn't be too bad.

Looking forward to the fix!

5

One last reply to state that Chef Infra Client 15.0.298 fixed this (as expected). I just watched a scheduled task run finish successfully (and will be rolling it out to the rest of our servers). Thanks to the Chef team for the quick responses - and quick fix!