On 10/24/2011 14:11, Chuck Swiger wrote:
On Oct 24, 2011, at 1:58 PM, A C wrote:
It has 16 MB of RAM right now (one stick). It had 64 at one point while I was
trying to diagnose this issue. I thought I might have a bad stick of RAM so I
was testing them one by one (one stick in the machine at a time). I didn't
reinsert the other three yet. But it doesn't matter, even with 64 MB ntpd
still crashes which is what started this whole debugging game in the first
place.
If ntpd crashes, you should get a coredump which you can debug (assuming you've
setup the coredumpsize limit to permit this) and perhaps a syslog message about
a SIGSEGV, SIGBUS, or whatever.
Not if it locks the system up entirely (as in I couldn't even break out
of the kernel) which is what had been happening. Turning off the
priority on ntpd (eliminating the use of the -N flag) seems to avoid the
system lock up issue but doesn't eliminate the ntpd lockup. The process
just sat there yesterday not doing anything and bogging the machine
down. The process itself doesn't die, there's no core to dump (yet), it
just sits and sits and sits...
Besides, I wouldn't call an Xterm and Xclock anything significant in the way of
X11 clients. I'm certainly not intending to run anything beyond those. The
Xterm is for a console and the Xclock I was using to keep an eye on the machine
so I'd know if the system locked up.
If you had 64MB of RAM, then the two clients wouldn't or shouldn't cause your
system to swap. With only 16MB, however, you're sure to be paging, and more
likely to be swapping entire processes out to disk
Again, the amount of memory is a distraction from the issue because even
with the 64 MB ntpd was having problems. But, I'll install the other
three sticks this week when I have an opportunity which will mostly
eliminate swapping issues.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
