On Saturday, September 22, 2012 3:58:41 AM UTC-5, Fabrice Bacchella wrote: > > > 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. > > SIGUSR1Immediately 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'm not well-versed in MCollective, but I would be surprised if it could not issue requests asynchronously. Even if it can't natively do so, whatever node is issuing the mco commands certainly can issue several of them asynchronously. > > 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. > > Puppet schedules are about what classes and resources are included in a catalog, not about whether the agent runs. Either I don't understand what you're trying to achieve, or I don't understand why it achieving it is a problem for you. There are basically three ways the Puppet configuration client can run: 1. as a periodic function of the puppet agent daemon. When, and only when, the agent is configured for this mode, you can additionally trigger an immediate configuration run at any time by having a local process issue Unix signal USR1 to the agent process. 2. as a remotely triggered function of the puppet agent daemon, via its listening interface. This vector is almost completely independent of (1); the two can be distinguished by whether a local process or a remote one triggers configuration runs. 3. via a one-time local command with --onetime --no-daemonize (which itself may optionally be issued by an automated process, perhaps initiated remotely) If you do not ever want the agent to initiate runs automatically, then either do not run it in daemon mode at all, or run it with --no-client --listen=true if you want to be able to trigger runs via the listening interface. Either way, you can always initiate runs locally according to (3), provided only that there is not already a configuration run in progress. So I agree with your initial premise that your task should be a simple one, and as far as I can tell that's what it is. You can run automatically at fixed intervals (or not), you can trigger runs via network messages to the Puppet agent's built-in network service, or you can trigger runs at will manually or via whatever scheduling program you like (cron, mco, ...). What else could Puppet reasonably offer that would make your task easier? Or else, what functionality is Puppet missing that is needed for this to work? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/sYOiSb2M17YJ. 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.
