Home/ Questions/Q 9071543
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T17:56:39+00:00

I have a Chef cookbook that includes the passenger_apache2::mod_rails recipe from the passenger_apache2 cookbook

  • 0

I have a Chef cookbook that includes the passenger_apache2::mod_rails recipe from the passenger_apache2 cookbook. On the server’s first Chef run, this created two (valid) configuration files:

# /etc/apache2/mods-available/passenger.load
LoadModule passenger_module /var/lib/gems/1.9.1/gems/passenger-3.0.11/ext/apache2/mod_passenger.so

# /etc/apache2/mods-available/passenger.conf
PassengerRoot /var/lib/gems/1.9.1/gems/passenger-3.0.11
PassengerRuby /usr/bin/ruby1.9.1
PassengerMaxPoolSize 6

These are created by using the cookbook’s templates passenger.load.erb and passenger.conf.erb, respectively, using node[:languages][:ruby][:ruby_bin] and node[:languages][:ruby][:gems_dir]. Those attributes are be automatically populated by Ohai.

On a second run of chef-client, these files get screwed up. Here’s how they look now:

# /etc/apache2/mods-available/passenger.load
LoadModule passenger_module /gems/passenger-3.0.11/ext/apache2/mod_passenger.so

# /etc/apache2/mods-available/passenger.conf
PassengerRoot /gems/passenger-3.0.11
PassengerRuby 
PassengerMaxPoolSize 6

So it appears that node[:languages][:ruby] is not getting populated during the Chef run. But if I call Ohai directly from an IRB session on the server, it appears correctly.

$ sudo -Hu root /usr/bin/irb1.9.1
irb(main):001:0> require 'yaml'
irb(main):002:0> require 'chef'
irb(main):003:0> node = YAML::load(`/usr/local/bin/ohai`)
irb(main):004:0> node['languages']['ruby']['ruby_bin']
=> "/usr/bin/ruby1.9.1"
irb(main):005:0> mash = Chef::Mash.new(node)
irb(main):006:0> mash[:languages][:ruby][:ruby_bin]
=> "/usr/bin/ruby1.9.1"

I can fix the file, but it won’t stop the problem from recurring on the next Chef run. I’m a bit stumped on how to appropriately troubleshoot this problem further.

Has anyone else run into this problem? I haven’t yet tried setting those attributes manually in my cookbook or role, but I don’t believe I should; automatic attributes are not supposed to be overridden.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think I solved this by just restarting chef-client, but I’m still stumped on the root cause.

    I believe that (at the time I experienced this problem) the running instance of the chef-client daemon was the original instance started when I bootstrapped the server with knife bootstrap. Our bootstrap template installs the ruby1.9.1 package, but maybe the chef-client daemon failed to load it properly. (I’m fuzzy on this.)

    I first tried adding ohai "reload" to my recipes, and on the next scheduled Chef run, the configuration files were still broken.

    Next I ran service chef-client restart, and then Chef populated the configuration files in question correctly. On the next run, they were still correct.

    So I am hoping this goes away, but I’m still befuddled why my running chef-client instance wasn’t capable of reloading automatic attributes from Ohai correctly. If anyone with deeper operational knowledge of Chef comes across this, I still welcome any comments or war stories.

    • 0