I've seen the same issue as well. I just tested then, adding a simple notify resource to a node and it took three consecutive runs of puppetd before the message appeared:
# puppetd --test info: Retrieving plugin info: Caching catalog for puppet-master-01 info: Applying configuration version '1289376693' notice: Finished catalog run in 30.24 seconds # puppetd --test info: Retrieving plugin info: Caching catalog for puppet-master-01 info: Applying configuration version '1289377768' notice: Finished catalog run in 24.98 seconds # puppetd --test info: Retrieving plugin info: Caching catalog for puppet-master-01 info: Applying configuration version '1289379786' notice: foo notice: /Stage[main]//Node[puppet-master-01]/Notify[test]/message: defined 'message' as 'foo' notice: Finished catalog run in 26.46 seconds # /opt/ruby-enterprise/bin/gem list *** LOCAL GEMS *** facter (1.5.8) fastthread (1.0.7) mysql (2.8.1) passenger (2.2.9) puppet (2.6.2) rack (1.1.0) rake (0.8.7) On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com> wrote: > I am having the same issue, and am running about the same stack. > > CentOS 5.5 > > facter (1.5.8) > fastthread (1.0.7) > passenger (2.2.15) > puppet (2.6.2) > puppet-module (0.3.0) > rack (1.1.0) > rake (0.8.7) > stomp (1.1.6) > > On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com> wrote: > > Patrick, thanks for the speedy reply once again. > > > I'm using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0. > > > From what I've read in this group and in Puppet Labs docs/wikis, > > Debian/Ubuntu users do seem to have an easier time generally than > > CentOS/Red Hat :-\ > > > Can I pass my command-line options to Puppetmasterd in the config.ru > > file? > > > -Kent > > > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote: > > > On Nov 9, 2010, at 9:34 AM, Kent wrote: > > > > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote: > > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote: > > > > >>> Hi all, > > > > >>> I'm a new puppet user and new to the forum. > > > > >>> I just switched my Puppetmaster to running inside Apache (via > > > >>> Passenger). When I make a change to a resource on the master, it > > > >>> sometimes takes a given node TWO runs before the master will realize > > > >>> the resource has changed and recompile a new catalog version for the > > > >>> node. For example, say my puppetmaster is serving configuration > > > >>> version '123' to a node. I change the file permissions for a file > > > >>> resource that's part of that catalog and then do a puppet run on the > > > >>> node. If I'm running with Passenger, the master serves config version > > > >>> '123' one more time (the agent makes no changes). The next time I run > > > >>> the node's agent, the master compiles new catalog version '456' and > > > >>> the agent makes the permission change. > > > > >>> A few items of note: > > > > >>> 1. This is not a problem with all changes to puppet module content. > > > >>> For example, if I change the source contents of a file in the 'files' > > > >>> directory of a module, the master will notice this immediately and > > the > > > >>> puppet agent on the node will grab the new file on the first run > > > >>> following the change on the master. > > > > >> Fact: > > > >> Files sent using "source" aren't part of the catalog. Instead, the > > client asks the server for them while the client is using the catalog and > > not during the compilation done on the server. > > > > >> Speculation: > > > >> I would guess this is because the problem you are having is happening > > during the compilation on the server. > > > > >>> 2. At first I thought maybe this was a timing issue (e.g. I was > > doing > > > >>> the puppet run too quickly after making the resource change) but it's > > > >>> not; whether I wait 5 seconds or 5 minutes before making the first > > > >>> puppet run, the master still doesn't notice the change. I set the > > > >>> 'filetimeout' setting in /etc/puppet/puppet.conf to 0 and it didn't > > > >>> help. > > > > >>> Any ideas on what's going on here? (thanks in advance for your help) > > > > > Ahh, Ok, that makes sense. The source files are not part of the > > > > manifests, just pointed to by them. > > > > > However, I am still having a problem with changed manifests not > > > > getting "noticed" by the Puppetmaster until the second run after it's > > > > been changed. This is only a problem when running puppetmaster as a > > > > rack app inside Apache. Of course, if I restart Apache it will serve > > > > up the most recent manifests on the first puppet run that connects to > > > > it, but it would be irritating to have to restart httpd every time I > > > > want to make a change to a module/manifest. > > > > > I also tried setting the puppet.conf option 'ignorecache = true' to no > > > > avail. (side note: on the "servertype" option in puppet.conf, official > > > > documentation still states that the only valid modes are 'webrick' and > > > > 'mongrel'. What is the appropriate mode for running with passenger?) > > > > My puppetmaster is working fine and that option isn't set which means > > it's defaulting to webrick. > > > > > Final note: The puppetmaster always logs that it has compiled a > > > > catalog and expired the cached one, even on the first runs where the > > > > new manifest does not yet take effect. (and annoyingly, puppetmaster > > > > under passenger now logs to /var/log/messages instead of /var/log/ > > > > puppet/puppetmaster.log; > > > > I don't know how to fix this, but this doesn't happen under Ubuntu. > > > > > it seems puppetmaster as a rack application > > > > does not look at /etc/sysconfig/puppetmaster - so I can't add options > > > > like verbosity, etc.) > > > > Correct. Files in /etc/sysconfig are red when a service starts. When > > using passenger, the service is apache and puppetmaster is one of it's > > subprocesses. > > > > The equivalent file is config.ru. It's in the folder you specify in the > > apache config file. Just do a "find / -name config.ru". > > > > That said, you really shouldn't need to change it if puppetmaster is > > managing to startup at all. > > > > > To me, it seems like there needs to be better Puppet Labs > > > > documentation on the differences between running Puppetmaster > > > > "normally" (e.g. with /etc/init.d/puppetmaster) versus as a Rack > > > > application. > > > > What distro are you using? > > > > What version of puppet are you using? (puppet --version) > > > > How did you install puppet? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
