Hi,
I have the following manifest that basically syncs the time for nodes really out
of sync and ntpd can''t drift the time back fast enough.
The problem is that when puppet executes the catalog, and puppet changes the
time, puppet never finishes because it can''t calculate the "run
time" since puppet changed the time during the puppet run.
Is this a bug? Should I do something different?
For example:
1. puppet starts at 3:53 pm
2. tmesync module alters the time accordingly back 10 minutes to 3:43
3. puppet is done, but never reports that it finished and appears hung since it
probably cant output a negative number anyways.
4. a restart of puppet seems to fix the issue until the time changes again.
# Class: timesync
#
# This module is a bandaid to keep virtual machines in sync with the time
server.
# This will basically sync the time whenver the time drifts out further than xx
seconds.
#
# Parameters:
#
# Actions: syncs the time with the timeserver
#
# Requires: timeoffset fact (esentially ntpdate -q ntpserver)
#
# Sample Usage:
#
class timesync {
# time in seconds that the clock needs to be out of sync before calling
ntpdate
$seconds=60
$timeserver="0.pool.ntp.org"
# only run max of six times per day
schedule { timecheck:
period => daily,
repeat => 6,
}
# only execute if time is out of sync by specified seconds
if ( $timeoffset > $seconds ){
exec{"synctime":
path => ["/bin", "/usr/bin/",
"/sbin", "/usr/sbin/"],
# schedule => timecheck,
command => "ntpdate $timeserver",
}
alert("Puppet had to sync the time as it was out of sync")
}
}
Corey Osman
corey@logicminds.biz
Green I.T and Datacenter Automation Specialist
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Excuse the pseudo-code, but could you pipe the "ntpdate" command to "at now +5 minutes"? It''ll exit with status 0, allowing puppet to go in its merry way, and the time will sync up "soon", hopefully before puppet runs again. If you could force the module to run very late in the chain, you could shorten the delay you feed to "at". Not sure if it''s a bug, but this dies seen to be a common enough issue with VMs. -- Mason Turner (mobile) On Dec 14, 2011, at 7:00 PM, Corey Osman <corey@logicminds.biz> wrote:> Hi, > > I have the following manifest that basically syncs the time for nodes really out of sync and ntpd can''t drift the time back fast enough. > > The problem is that when puppet executes the catalog, and puppet changes the time, puppet never finishes because it can''t calculate the "run time" since puppet changed the time during the puppet run. > > Is this a bug? Should I do something different? > > For example: > > 1. puppet starts at 3:53 pm > 2. tmesync module alters the time accordingly back 10 minutes to 3:43 > 3. puppet is done, but never reports that it finished and appears hung since it probably cant output a negative number anyways. > 4. a restart of puppet seems to fix the issue until the time changes again. > > # Class: timesync > # > # This module is a bandaid to keep virtual machines in sync with the time server. > # This will basically sync the time whenver the time drifts out further than xx seconds. > # > # Parameters: > # > # Actions: syncs the time with the timeserver > # > # Requires: timeoffset fact (esentially ntpdate -q ntpserver) > # > # Sample Usage: > # > class timesync { > > # time in seconds that the clock needs to be out of sync before calling ntpdate > $seconds=60 > > $timeserver="0.pool.ntp.org" > > > # only run max of six times per day > schedule { timecheck: > period => daily, > repeat => 6, > } > # only execute if time is out of sync by specified seconds > if ( $timeoffset > $seconds ){ > exec{"synctime": > path => ["/bin", "/usr/bin/", "/sbin", "/usr/sbin/"], > # schedule => timecheck, > command => "ntpdate $timeserver", > > } > > alert("Puppet had to sync the time as it was out of sync") > } > > > } > > > Corey Osman > corey@logicminds.biz > Green I.T and Datacenter Automation Specialist > > > > -- > 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+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Dec 14, 2011 at 16:00, Corey Osman <corey@logicminds.biz> wrote:> I have the following manifest that basically syncs the time for nodes really out of sync and ntpd can''t drift the time back fast enough. > > The problem is that when puppet executes the catalog, and puppet changes the time, puppet never finishes because it can''t calculate the "run time" since puppet changed the time during the puppet run. > > Is this a bug? Should I do something different?Wow. Personally, I used custom logic from cron, and at boot, so that having Puppet broken because SSL is time sensitive and can have ... headaches if it is too far out of sync, but there is no theoretical reason that can''t work. You might want to consider using an exec with an `unless` or `onlyif` clause so that the check and sync are both local to the client instead of using a fact that requires the server to sign-off. That means that the default of using the cached catalog on failure will fix time sync that breaks SSL. Fundamentally, though, changing time like that should not break a Puppet run, full stop. We should cope, and carry on, regardless of what happens to the clock. (Reporting bogus timing data? Don''t really mind that so much. :) So, yeah, please turn this into a bug report. We should totally fix that up some time. (haha) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.