It's only drastic if you're worried about not having your machines' logs in the
same log file at the same time (because you log locally). 100 machines is as
good a time to start logging non-locally as any.
If anybody didn't want to get that drastic, they could always $rotateminute = 0
+
Randomizing the time of logrotation as a workaround for this particular
issue seems drastic to me.
https://docs.puppetlabs.com/references/latest/configuration.html#splay
This may do the trick.
Cheers,
Felix
On 01/08/2015 08:27 PM, Christopher Wood wrote:
Yes it does, and that's something that
Hi All,
I have found one more issue.
When we install puppet agent, it creates logrotate which will kill the
puppet and restart it. We have configured logroate for all the nodes at
1st minute of everday(00:01). Because of that all the node's puppet agent
get reloaded at 00:01 minutes so
Yes it does, and that's something that you would configure to not happen at the
same time (with fqdn_rand, or better, remote syslog).
https://docs.puppetlabs.com/references/latest/function.html#fqdnrand
I found some irritating hitches with running through a cut-down environment
using
Following up to myself since it turned out that running puppet agents via cron
was better for us due to one important feature...
[cwood@client ~]$ mcod puppet runonce --environment=puppetupgrades --no-splay
-F hostname=puppetmasterlab
running: mco puppet -c /home/cwood/.mcollective.dev runonce
Try using the splay config option on the agents. It should help to
distribute the agent runs.
https://docs.puppetlabs.com/references/latest/configuration.html#splay
If that fails, you could try running the puppet agent from a cron job
instead with randomised start times as per the below link.
On 11/06/2014 09:25 AM, james.eckers...@fasthosts.com wrote:
If that fails, you could try running the puppet agent from a cron job
instead with randomised start times as per the below link.
+1
I have yet to see a disadvantage of cron vs. the background agent.
--
You received this message
I used to have issues with the agent leaking memory over time. This is
going back to 2.6 days.
I implemented a cron job back then to restart the agent every night and
never removed the job (even though I'm now running 3.6), so I don't know if
there are still memory issues with the agent
On Thu, Nov 06, 2014 at 09:28:32AM +0100, Felix Frank wrote:
On 11/06/2014 09:25 AM, james.eckers...@fasthosts.com wrote:
If that fails, you could try running the puppet agent from a cron job
instead with randomised start times as per the below link.
+1
I have yet to see a
