Le 21 sept. 2012 à 15:35, jcbollinger a écrit : > > > On Friday, September 21, 2012 6:21:04 AM UTC-5, Fabrice Bacchella wrote: > When puppet is launched as a daemon, a kill -USR trigger a catalog run : > > Sep 21 12:56:01 XXX puppet-agent[15324]: Caught USR1; calling reload > Sep 21 12:56:24 XXX puppet-agent[15324]: Finished catalog run in 12.96 > seconds > > But when launched with --listen --no-client, nothing happens any more : > > Sep 21 13:01:44 XXX puppet-agent[16858]: Caught USR1; calling reload > Sep 21 13:02:21 XXX puppet-agent[16858]: Caught USR1; calling reload > > With only --listen, it still works. > > > Yes, that's exactly what I would expect. With --no-client, the agent only > requests a catalog when it is signaled by the master. The response to > SIGUSR1 is a function of the client mode.
But in the manpage : --no-client Do not create a config client. This will cause the daemon to run without ever checking for its configuration automatically, and only makes sense when puppet agent is being run with listen = true in puppet.conf or was started with the --listenoption. SIGUSR1 Immediately retrieve and apply configurations from the puppet master. runinterval How often puppet agent applies the client configuration; in seconds. Note that a runinterval of 0 means “run continuously” rather than “never run.” If you want puppet agent to never run, you should start it with the --no-client option. Default: 1800 How can I understand that you say from the documentation ? It says "checking for its configuration automatically", that's not the same thing as reacting to a signal. Reacting to SIGUSR1 is the same kind of comportment as client : puppet waiting for external signals. The should go together. > > > I want to launch puppet in listen only mode, and schedule it using > mcollective, but because a stack of different bugs, what should be a simple > task is becoming a nightmare. > > There is this one. > > But there is also : > http://projects.puppetlabs.com/issues/4411 > http://projects.puppetlabs.com/issues/8917 > > Can someone show me a way out of this maze ? > > > I'm not very familiar with using MCollective to schedule Puppet runs, but > bugs notwithstanding, it looks like you are asking for more from Puppet than > you need to achieve that. > > Have you considered not running the agent in daemon mode at all? You should > be able to use mco to perform "puppet agent --onetime --no-daemonize" at > need. If you don't *also* need the ability for the master to trigger Puppet > runs over the listen interface, or for local processes to trigger runs via > SIGUSR1, then that should completely cover your needs. When running using puppet through mco with onetime once, the run is synchrone : each catalog puppet must be finished before going to the next, it's too slow. When puppet is running as a daemon, the run is asynchrone and so much faster. I was thinking about using the schedule type (http://docs.puppetlabs.com/references/latest/type.html#schedule), but I'm loosing hope. I don't expect it to run when runinterval is disabled, even if I think it should be. > > Even if you are running the agent with --listen --no-client (more on that in > a moment), you can still trigger one-off agent runs of the puppet agent as > described above. That's safe inasmuch as Puppet uses a lock file to prevent > overlapping runs. > > You can work around the issue of agent options not recognized in the config > file via Puppet's sysconfig interface (in some versions of Puppet, at least) > or by modifying the actual service management script. With the sysconfig > interface, for example, you would install a file /etc/sysconfig/puppet, > containing at least: > > PUPPET_EXTRA_OPTS==--no-client > > to make the service control script provide that option directly when it > launches the agent. > > If it essential that the agent accept SIGUSR1 to trigger a catalog cycle, > then you must run in daemon mode with the client enabled (but --listen is not > relevant to this question). In that case you could consider setting the run > interval to something very long, so that automated runs are very rare (except > that runs will always happen at service startup). very rare and at service startup is not the same thing as never. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
