Date: Thu, 26 Apr 2012 11:15:33 -0500 From: "Dean Weimer" <dweimer@ORSCHELN.com> To: "Cy Schubert" <Cy.Schubert@komquats.com> Cc: ports@FreeBSD.org, cy@FreeBSD.org Subject: RE: FreeBSD Port: ntp-4.2.6p5 Message-ID: <CACC65656ED5C44FBA651F3D2B99B808354A3ECD@neuman.orscheln.oi.local> References: Message from "Dean Weimer" <dweimer@orscheln.com> of "Wed, 25 Apr 2012 09:54:28 CDT." <CACC65656ED5C44FBA651F3D2B99B808354A375E@neuman.orscheln.oi.local> <201204252130.q3PLUchS003768@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message-----
From: Dean Weimer=20
Sent: Thursday, April 26, 2012 8:37 AM
To: 'Cy Schubert'
Cc: cy@FreeBSD.org; ports@FreeBSD.org
Subject: RE: FreeBSD Port: ntp-4.2.6p5
I have duplicated this problem on a second machine, both are running on
identical physical hardware (Dell PowerEdge R310, purchased on same
order), cannot duplicate it anywhere else. The version of Pearl had
nothing to do with it, nor does it matter if openssl is selected during
the build process. I have also discovered that the -d option isn't
necessary, it will run fine just by using -n. I have worked around it
for the time being by manually executing it use the daemon command to
detach it from the terminal session. I have three other systems that
are not experiencing the problem, first one is my test system where I
test application updates first, its running in VMware workstation, one
production system on older custom built hardware, and another on VMware
ESX 4 server. The two PowerEdge servers are 4G memory and 4 core CPU.
My other systems all had 2 cores/cpu emulation and 2G memory. So I
modified the test system to match that in case that had anything to do
with it. No dice, test system still worked fine.
Oddly I wasn't having this problem prior to the opnessl-1.0.1_1 update
coming out, and the recompile occurred via portmaster -r update to
openssl. Removing openssl from the ntp options doesn't fix it; I find
it hard to believe that the two servers suddenly have a memory issue at
the same time, though they could very well have the same defect as they
likely came out of the same lot of hardware. Here is the output of a
sysctl -a from one of the systems.
[...snip...]
Further info, it's not actually syncing time when running in debug mode
or with the -n on these systems. I created a package from one of the
running systems and installed the package to the non-working systems no
change, so it doesn't appear to be the compile process where the problem
is originating.
Thanks,
Dean Weimer
Network Administrator
Orscheln Management Co
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACC65656ED5C44FBA651F3D2B99B808354A3ECD>