Folks, If we can RLIMIT_MEMLOCK on a machine we will do so by default. For most every platform out there, a 32M limit is sufficient (and I think it used to be smaller). For some Linux admins, they are discovering that sometimes values as high as 128M are insufficient.
We know better timekeeping happens when ntpd can quickly respond, so by default we lock ntpd into memory. This is a good news/bad news tradeoff. Here's a partial list of ways to address it. - default it to 0, and force every admin to set it to something if they want this. This will cause a Lot of work for people. - leave it alone, and document that if they get these crashes (I don't think we can trap these crashes but if we can we could offer a helpful message) they should bump their 'rlimit memlock XX' up or set it to 0. - add more logic to configure, so if we detect that we're running on an OS that is prone to these problems we select a bigger default As I said, there are pros/cons to all of these choices. Also see http://support.ntp.org/bin/view/Support/LockingNtpdInMemory -- Harlan Stenn <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
