On 02/16/2011 11:30 AM, Derek J. Balling wrote: >> For what it is worth, for an extremely well known interface like >> /etc/resolv.conf I would subscribe to the file resource, but for most >> cases I prefer to depend on the class. So, I think both answers are >> right, and I didn't explain why I chose the apparently tighter binding >> this time around. > > FWIW, we've chosen to do both, if for no other reason than so that the app in > question won't be "processed" until after the resolv.conf is updated, so we > can minimize the number of restarts, etc., as necessary. > > The next issue which follows, for me, is that "random_app" is "puppet-agent", > because it refuses to notice changes to resolv.conf, and has to be restarted > to pick them up. Likely this is because it's using its own resolver library > instead of the system calls, but this is a real PITA, since the only "clean" > way to restart the puppet agent, from within puppet, essentially amounts to > issuing `/etc/init.d/puppet restart`in the middle of a catalog-run, which > sucks for all the obvious reasons you would think it does.
Yes. Ugly workaround: Schedule the restart using atd from within the catalog run. (I've used "at now+2min" and it works so far). Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
