ability to set chef_client.config.file_atomic_updates attrib

[epcim]

The chef-client should be able to set all it;s attrib dynamically from node[chef_client.config] array. I have a need to set file_atomic_update to false from an .kitchen.yml spec. - as an example.

is that possible or that is really missing?

[juliandunn]

Sure... why can't you just set ['chef-client']['config']['file_atomic_update'] yourself as an attribute?

[huntertj]

setting this as an attribute isn't a solution. For me setting file_atomic_update its to workaround a docker issue where I cannot update /etc/hosts see moby/moby#9295

[juliandunn]

@huntertj I'm not sure what you mean by that "setting this as an attribute is not a solution" -- isn't that what the OP is asking here?

[huntertj]

If I'm using a community cookbook I need be able to set this in my .kitchen.yml so i don't need to edit a cookbook

[juliandunn]

Still don't understand what you mean. You can set attributes in your .kitchen.yml that will be respected by Chef e.g.

platforms:
  - name: whatever
    attributes:
      chef-client:
        config:
          file_atomic_update: true

?

[huntertj]

Sorry, need to be more clear when I set this as an attribute in my .kitchen.yml it does not resolve the docker issue referenced above moby/moby#9295
I assumed this was because file_atomic_update was not being respected in .kitchen.yml

[juliandunn]

You can check inside /etc/chef/client.rb in the container to see whether it's being respected or not

[epcim]

@huntertj - actually you do have to set it to False (the opposite of the Default value - https://docs.chef.io/config_rb_client.html)

My experience - actually when set in .kitchen.yml in the attributes section it resolve the issue, but it probably depends usage - or - how many times your cookbooks modify the /etc/hosts. In my case, one resource provider modifying the file in base cookbook works just fine, however I was using hostsfile cookbook resource providers quite frequently and than it fails.

So technically it's still not properly supported, since if chef-client is running in a container, assuming modification of /etc/hosts are supported (and they are in latest version) then it should treat modifications of these resources like /etc/hosts /etc/resolve.conf.

[huntertj]

@epcim, thanks for the additional info
@juliandunn thanks for the tip on looking in /etc/chef/client.rb
unfortunately this can be closed, probably should be an open issue in docker for shared resources but it was closed there as an issue in chef moby/moby#9295

[juliandunn]

Great. Thanks @huntertj

[lamont-granquist]

I kinda want to scream this as loud as possible:

SETTING FILE_ATOMIC_UPDATES TO FALSE GLOBALLY IS NOT A FIX PLEASE DO NOT DO THAT OR YOU RISK CRASHING YOUR PRODUCTION ENVIRONMENT.

This setting should probably be ripped out of Chef::Config because using it globally to fix an issue in docker containers with the hostsfile cookbook not setting it is just abuse of the setting.

The way that it will make your life unhappy is:

• One night your apps will start logging a LOT for some reason
• Logfile rotation/deletion will be unable to keep up with the load
• Your disks will fill up to 100%
• Before you can react chef-client will run
• At some point chef-client will write a truncated file due to being out of disk space and crash
• If that truncated file is critical you may lose your entire fleet of app servers and your app may crash

The ability of root to write past 100% (the reserved space on the disk) may save you, but all it takes is chef-client or some other root-run process pushing around a large enough file for that process to run out of space as well.

And if you set this value in test-kitchen and do not set it in production you invalidate your testing and could see failures in prod related to the non-use of this setting compared to your testing environment.