Ask Your Question

SOME agents _not_ copying module's facts.d. Most work

asked 2015-01-23 12:28:23 -0500

samircury gravatar image

updated 2015-01-23 12:33:49 -0500

I would understand this problem better if it affected all clients equally but it doesn't.

A long time after changes in the master (24h+), to make sure there are no caches, after several "puppet agent -t" runs, in short this is what I get :

[root@host1 ~]# find /var/lib/puppet/ -name discover-hdfs-partitions.*

[root@host2 ~]# find /var/lib/puppet/ -name discover-hdfs-partitions.*
[root@host2 ~]#

As it helps debugging, here's the first puppet run (after completely wiping the agent, reinstalling RPM, revoking certificate and starting from scratch) :

As you see the fact file is pretty much ignored and not copied.

Both agents have the same exact version :


And the master is the same. (very close if not the same 3.7 release)

Any clues on how to debug this further? I have close to 300 nodes and most of them are fine. Few are presenting this but is enough to create the mess.


For completeness, this is where the custom fact sits on the module :


And healthy nodes will use the fact for a notify among other things :

Notice: /Stage[main]/Hdfs::Datanode/Notify[Found the following HDFS data mountpoints: /data1/hadoop/data,/data2/hadoop/data]/message: defined 'message' as 'Found the following HDFS data mountpoints: /data1/hadoop/data,/data2/hadoop/data'

edit retag flag offensive close merge delete


Just found that if I copy the file by hand there, it still doesn't work, but if I run the fact by hand it works : [root@host3 ~]# /var/lib/puppet/facts.d/ hdfs_partitions=/data1/hadoop/data,/data2/hadoop/data,/data3/hadoop/data So maybe not related to the file transfer

samircury gravatar imagesamircury ( 2015-01-23 13:07:59 -0500 )edit

Can you post a link to a pastebin of the source of

GregLarkin gravatar imageGregLarkin ( 2015-01-23 16:29:28 -0500 )edit I also tried with "/usr/bin/perl" to prevent $PATH related problems, but no luck.

samircury gravatar imagesamircury ( 2015-01-23 17:31:39 -0500 )edit

Are the script ownership and permissions set correctly so it's executable by the user/group that owns the Puppet agent process?

GregLarkin gravatar imageGregLarkin ( 2015-01-26 08:43:55 -0500 )edit

sudo -u puppet /var/lib/puppet/facts.d/ hdfs_partitions=/data1/hadoop/data [root@host4 ~]# ll /var/lib/puppet/facts.d/ -rwxr-xr-x. 1 puppet puppet 183 Jan 27 09:53 /var/lib/puppet/facts.d/ Looks like all is fine.

samircury gravatar imagesamircury ( 2015-01-27 12:02:26 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2015-02-04 18:21:42 -0500

samircury gravatar image

So it turned out that due to site-specific details, I got puppet 3.7 but an older facter (1.7) in the nodes affected. Ensuring that facter was the latest in the site basic configuration was enough to get the right fact working everywhere. module/facts.d/ looks a valid location to store non-ruby custom facts within the module.

Documentation referencing it is here :

Thanks to all reading and suggesting!

edit flag offensive delete link more

answered 2015-01-27 22:26:13 -0500

GregLarkin gravatar image

You indicated that your custom fact script is placed in modules/hdfs/facts.d/ Can you switch its location to modules/hdfs/lib/facter/ and try again?

In order for custom facts to be distributed to the agents, they have to be located in your module according to this layout:

edit flag offensive delete link more


Thanks, I tested that and it works, for ruby facts. My custom fact is a bash script and using it like that would be like on the old times that one had to call a ruby script to call a bash script. While looking at that I found the problem. Posting the reason below.

samircury gravatar imagesamircury ( 2015-02-04 18:08:37 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-01-23 12:28:23 -0500

Seen: 184 times

Last updated: Feb 04 '15