Puppet

Updated some machines to 0.25.3 masters and client:

same script as before, same config as before:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unable to set config_version: Execution of '/usr/local/bin/getrevision.sh' returned 1:  on node monitor2.my.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

-rwxr-xr-x 1 root root 71 Jan 13 21:22 /usr/local/bin/getrevision.sh
# su - puppet
% /usr/local/bin/getrevision.sh
4602
% echo $?
0

Ah, obviously yesterday I had just /bin/date in my script and not something that retrns a number. Have retested:

• with /bin/date in the shell script i get the returned 1 error
• with config_version running /bin/date it works as expected

Any suggestions on how to replicate it? Also, does it work with an “exit 0” in the script? The only way I can see to make this happen is to have the script fail with an exit code of 1, which (it appears) should not be the case.

Markus Roberts wrote:

Any suggestions on how to replicate it? Also, does it work with an “exit 0” in the script? The only way I can see to make this happen is to have the script fail with an exit code of 1, which (it appears) should not be the case.

have attempted to recreate on a Debian machine and it works fine. I think I’m about happy to say this is either some weird centos thing – though Dan cant reproduce on centos either – or more likely something specific to my environment.

I used to be able to reproduce on CentOS 5, but testing with 0.25.5 I now cannot.

(I was happy to find it working until I realized that the config_version script is only called once, when puppetmasterd starts. So if I have /bin/date or a more complex script to divine the current git commit id, the value is not updated unless puppetmasterd is restarted. Which makes this less than useful. Is that worthy of a separate bug or similar enough to warrant investigating here?)

Todd Zullinger wrote:

I used to be able to reproduce on CentOS 5, but testing with 0.25.5 I now cannot.

(I was happy to find it working until I realized that the config_version script is only called once, when puppetmasterd starts. So if I have /bin/date or a more complex script to divine the current git commit id, the value is not updated unless puppetmasterd is restarted. Which makes this less than useful. Is that worthy of a separate bug or similar enough to warrant investigating here?)

Really? that’s not my experience. At the moment my hacky solution is to have the script that updates my svn checkout leave a file, then in puppet.conf I have:

    config_version      = /bin/cat /etc/puppet/manifest-version.txt

And as soon as my SVN updates my machines start reporting the right version

It seemed odd, and I thought when I tested in earlier versions with the commands directly in puppet.conf if behaved as you describe. I tested on a CentOS 5 and Fedora 10 puppetmaster, both at 0.25.5. Until I restart puppetmasterd, clients display the value from the script when puppetmasterd was started.

I’m not sure which, if any, cache settings might affect this. I ran puppetd -tv —ignorecache on some clients and that didn’t do it.

Is this perhaps a difference between different server types? eg webrick vs mongrel vs passenger?

If I’m not mistaken, we’ve drifted into discussing another possible bug, not directly related to this ticket, specifically the question of when the config_version is refreshed (e.g., if you have to restart puppet).

This is an interesting issue in its own right (e.g., are there synchronization issues between the manifest and the config version created by this, esp. with regard to the file timeout) but it doesn’t belong on this ticket—probably #3692 would be a better place for it.

As for the script vs. executable issue, does anyone have a repeatable instance of this or know what we would need to do to make it happen?

Markus Roberts wrote:

If I’m not mistaken, we’ve drifted into discussing another possible bug, not directly related to this ticket, specifically the question of when the config_version is refreshed (e.g., if you have to restart puppet).

This is an interesting issue in its own right (e.g., are there synchronization issues between the manifest and the config version created by this, esp. with regard to the file timeout) but it doesn’t belong on this ticket—probably #3692 would be a better place for it.

As for the script vs. executable issue, does anyone have a repeatable instance of this or know what we would need to do to make it happen?

I can reproduce it on one machine, not on another running a different OS. I think its machine specific so I think we can kill this bug.

Markus Roberts wrote:

I’ll drop it to low, but rather than killing it outright I’ll leave it open for a while in the hopes that we can at least figure out what the problem is. What happens if you try even simpler scripts, such as echoing a constant string, exiting with 0, etc.? Can you try tee-ing the output to a file and checking 1) to make sure it’s getting run at all and 2) see if the file contents look correct? And so forth?

— Markus

I pretty much tried all these before going for the current hack solution I have that calls /bin/cat on a file i prepare from cron, sucky.

I will spend some more time on this soon

Can’t recreate this in 2.6.1rc3, lets just close this.