Michael, Are you up for submitting a patch?
H -- >>> In article <%a7bvjf...@khar-pern.talamasca.ocis.net>, Michael Deutschmann >>> <mich...@talamasca.ocis.net> writes: Michael> I now have NTP-with-mlockall() installed and chiming on my Linux Michael> systems. Michael> On Fri, 19 Dec 2008, Harlan Stenn wrote: >> Please see http://support.ntp.org/bin/view/Support/LockingNtpdInMemory >> and the related links on that page. >> >> http://support.ntp.org/bin/view/Dev/NewNtpConfFormat#Memory_locking also >> has some information that might be useful. Michael> I've looked into those links. Sounds like the problem is not Michael> actually mlockall(), it's setrlimit(). Michael> When using mlockall(), ntpd adjusts the stack limit downward, out Michael> of fear that the operating system will deny the lock unless it can Michael> pre-commit real memory for the worst-case stack size. Michael> Glibc's resolver is apparently a stack hog, and chafes under a Michael> limit which is otherwise comfortable for ntpd. Michael> Denying mlockall() only solves the problem because then ntpd won't Michael> bother with setrlimit(). Michael> If so, then the cure is simple: When a resolver process is forked, Michael> it's first act should be to reset the stack limit to what it was in Michael> the first place. There's no worry about overcommitting real Michael> memory, because mlockall() is not inherited across forks. Michael> ---- Michael Deutschmann <mich...@talamasca.ocis.net> -- Harlan Stenn <st...@ntp.org> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
