I applied the template Server Clock Drift (powershell) and it's working on almost all of my servers. I'm getting the attached error message on one of them. Does anyone know what would cause this?
I applied the template Server Clock Drift (powershell) and it's working on almost all of my servers. I'm getting the attached error message on one of them. Does anyone know what would cause this?
There is a bug in the Server Clock Drift (Powershell) - Clock Drift NTP component. If you make the following changes it should work reliably, I think.
Starting around line 24...
=====
If ($remoteToSolarSkew…
Thank you dthvt for bringing this to our attention (and even suggesting a fix!). I've logged this internally under FB383456 and will investigate the issue. We will likely be updating the template posted…
Is the error you're receiving persistent for these nodes or does this only occur occasionally?
Is there any common thread between these hosts that are exhibiting the problem? Are they all running the the same operating system version for instance?
We've done some investigation internally and believe the issue is that the default configured NTP server defined in the template is blocking your connection intermittently. If you have many servers configured with this template than it's possible you are exceeding their maximum rate of querying once every 4 seconds on occasion.
All users should ensure that their software NEVER queries a server more frequently than once every 4 seconds. Systems that exceed this rate will be refused service. In extreme cases, systems that exceed this limit may be considered as attempting a denial-of-service attack.
To resolve this issue I recommend changing the time server configured for some nodes to use pool.ntp.org instead.
Based on the message returned it appears that host is blocking connections. The good news is there's plenty of publicly accessible NTP servers. Below is a list of a few of them from http://tf.nist.gov/tf-cgi/servers.cgi
Name | IP Address | Location |
nist1-ny.ustiming.org | 64.90.182.55 | New York City, NY |
nist1-nj.ustiming.org | 96.47.67.105 | Bridgewater, NJ |
nist1-nj2.ustiming.org | 165.193.126.229 | Weehawken, NJ |
nist1-ny2.ustiming.org | 216.171.112.36 | New York City, NY |
nist1-pa.ustiming.org | 206.246.122.250 | Hatfield, PA |
time-a.nist.gov | 129.6.15.28 | NIST, Gaithersburg, Maryland |
time-b.nist.gov | 129.6.15.29 | NIST, Gaithersburg, Maryland |
time-c.nist.gov | 129.6.15.30 | NIST, Gaithersburg, Maryland |
time-d.nist.gov | 2610:20:6F15:15::27 | NIST, Gaithersburg, Maryland |
nist1.aol-va.symmetricom.com | 64.236.96.53 | Reston, Virginia |
nist1-macon.macon.ga.us | 98.175.203.200 | Macon, Georgia |
nist1-atl.ustiming.org | 64.250.177.145 | Atlanta, Georgia |
wolfnisttime.com | 207.223.123.18 | Birmingham, Alabama |
nist1-chi.ustiming.org | 216.171.120.36 | Chicago, Illinois |
nist.time.nosc.us | 96.226.242.9 | Carrollton, Texas |
nist.expertsmi.com | 162.17.148.102 | Monroe, Michigan |
nist.netservicesgroup.com | 64.113.32.5 | Southfield, Michigan |
nisttime.carsoncity.k12.mi.us | 66.219.116.140 | Carson City, Michigan |
nist1-lnk.binary.net | 216.229.0.179 | Lincoln, Nebraska |
wwv.nist.gov | 24.56.178.140 | WWV, Fort Collins, Colorado |
time-nist.symmetricom.com | 12.10.191.251 | Symmetricom, Boulder, Colorado |
time-a.timefreq.bldrdoc.gov | 132.163.4.101 | NIST, Boulder, Colorado |
time-b.timefreq.bldrdoc.gov | 132.163.4.102 | NIST, Boulder, Colorado |
time-c.timefreq.bldrdoc.gov | 132.163.4.103 | NIST, Boulder, Colorado |
time.nist.gov | global address for all servers | Multiple locations |
utcnist.colorado.edu | 128.138.140.44 | University of Colorado, Boulder |
utcnist2.colorado.edu | 128.138.141.172 | University of Colorado, Boulder |
ntp-nist.ldsbc.edu | 198.60.73.8 | LDSBC, Salt Lake City, Utah |
nist1-lv.ustiming.org | 64.250.229.100 | Las Vegas, Nevada |
time-nw.nist.gov | 131.107.13.100 | Microsoft, Redmond, Washington |
nist-time-server.eoni.com | 216.228.192.69 | La Grande, Oregon |
nist1.symmetricom.com | 69.25.96.13 | San Jose, California |
nist1-sj.ustiming.org | 216.171.124.36 | San Jose, California |
nist1-la.ustiming.org | 64.147.116.229 | Los Angeles, California |
There is a bug in the Server Clock Drift (Powershell) - Clock Drift NTP component. If you make the following changes it should work reliably, I think.
Starting around line 24...
=====
If ($remoteToSolarSkew)
{
$Skew = $remoteToSolarSkew.TotalSeconds - $ntpToSolarSkew;
$stat=[math]::round($Skew,2);
#$symb=$Skew.ToString().Substring(0,1);
$symb=$stat.ToString().Substring(0,1);
if ($symb -eq "-")
{
#$stat=[math]::round($Skew,2);
$tmp=$stat.ToString().Remove(0,1);
Write-Host "Message: Clock drift: $stat.";
Write-Host "Statistic: $tmp";
exit 0;
}
else
{
$stat=[math]::round($Skew,2);
#Write-Host "Message: Clock drift: $symb $stat s.";
Write-Host "Message: Clock drift: $stat s.";
Write-Host "Statistic: $stat";
exit 0;
}
}
=====
aLTeReGo - not sure if you can validate whether this error exists in the version on thwack. The version that ships with SAM 6.1.1 has the error it. By way of explanation, the error is that calling ::round() on a number like -0.00121 will be rounded to 0.00 (notice the negative sign was dropped). But the $symb is set prior to rounding, so the logic for removing the negative symbol is used on a string with no negative symbol, which then results in $stat printing an empty string instead of a 0.
Thank you dthvt for bringing this to our attention (and even suggesting a fix!). I've logged this internally under FB383456 and will investigate the issue. We will likely be updating the template posted in the Content Exchange accordingly.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 190,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.