template file being generated with zero bytes - checksum thinks file is correctly populated (Adam Jacob looked at this and said to submit a ticket)

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 0.10.2
  • Fix Version/s: None
  • Component/s: Chef Client
  • Labels:
    None
  • Environment:

    HP Cloud Servers AW1 Clusters

Description

This is 100% reproducible on our systems. It happens with many files (not just the example below):

There is a file that was created by chef at some point in the past with zero bytes (should never have been zero bytes - that is a bug to begin with):

root@az1-nv-compute-0007:/home/schermerhorn/.ssh# ls -l authorized_keys
-rw-r--r-- 1 root root 0 2011-10-21 15:45 authorized_keys

There is a recipe that gets run to create that file:

template "#/home/schermerhorn/.ssh/authorized_keys" do
  source "authorized_keys.erb"
  variables :ssh_keys => params[:ssh_keys]
  owner "root"
  group "root"
  mode "0644"
end

The erb file looks like this:

# Important Note -
# Ownership of this keyring is root:root for a very good reason. :-)
# Keyring is being managed centrally by Chef - all changes will be reverted.
# -----------------------------------------------------------------------------
<%= @ssh_keys %>

Chef is processing the resource:

[Wed, 30 Nov 2011 21:22:23 +0000] INFO: Processing template[/home/schermerhorn/.ssh/authorized_keys] action create (users::ssh-keys line 26)

Yet when done - the file still has zero bytes (it was not updated) - Why? This seems like a chef bug.

root@az1-nv-compute-0007:/home/schermerhorn/.ssh# ls -l
-rw-r--r-- 1 root root 0 2011-10-21 15:45 authorized_keys

The checksum file has same timestamp:

root@az1-nv-compute-0007:/var/cache/chef/checksums# ls -l *schermer*
-rw-r--r-- 1 root root 100 2011-10-21 15:45 chef-file--home-schermerhorn--ssh-authorized_keys

If I touch /home/schermerhorn/.ssh/authorized_keys to change its timestamp and re-run chef, the file gets recreated with the 643 bytes is should have:

root@az1-nv-compute-0007:/home/schermerhorn/.ssh# ls -l
-rw-r--r-- 1 root root 643 2011-11-30 21:27 authorized_keys

The salient items from a debug run are:

[Wed, 30 Nov 2011 21:58:40 +0000] INFO: Processing template[/home/schermerhorn/.ssh/authorized_keys] action create (users::ssh-keys line 26)
[Wed, 30 Nov 2011 21:58:40 +0000] DEBUG: Not storing cookbooks/users/templates/default/authorized_keys.erb, as the cache is up to date.
[Wed, 30 Nov 2011 21:58:40 +0000] DEBUG: Current content's checksum:  b8f189753151b88066d49093e29924e44582c9b9f5895f0c373013c0243787c4
[Wed, 30 Nov 2011 21:58:40 +0000] DEBUG: Rendered content's checksum: b8f189753151b88066d49093e29924e44582c9b9f5895f0c373013c0243787c4

The file /var/cache/chef/cookbooks/users/templates/default contains:

# Important Note -
# Ownership of this keyring is root:root for a very good reason. 
# Keyring is being managed centrally by Chef - all changes will be reverted.
# -----------------------------------------------------------------------------
<%= @ssh_keys %>

Yet the /home/schermerhorn/.ssh/authorized_keys file is still zero bytes - it should at least have the comment lines!

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jim Wichelman added a comment -

The corresponding HP ticket is: DATE-458

Show
Jim Wichelman added a comment - The corresponding HP ticket is: DATE-458
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Fixed the formatting by adding {code} macros around code in the ticket description.

Show
Bryan McLellan [Opscode] added a comment - Fixed the formatting by adding {code} macros around code in the ticket description.
Hide
Permalink
Jim Wichelman added a comment -

We are seeing other files being created with zero bytes that have nothing to do with chef. So this is starting to feel like an kernel/file-system problem. Will keep you posted.

Show
Jim Wichelman added a comment - We are seeing other files being created with zero bytes that have nothing to do with chef. So this is starting to feel like an kernel/file-system problem. Will keep you posted.

People

  • Assignee:
    Unassigned
    Reporter:
    Jim Wichelman
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: