[ntp:questions] Running two ntpd systems in parallel

Paul Fleischer paul at xpg.dk
Fri Oct 30 08:30:41 UTC 2009


2009/10/17 Dave Hart <davehart at gmail.com>:
> On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer <paul at xpg.dk> wrote:

> I would like to see ntpd support unprivileged operation for testing
> purposes, including using a local port > 1024.  The approach I have
> been considering is adding a "port" option to the association commands
> like server and peer in ntp.conf, with the secondary or unprivileged
> ntpd still defaulting to remote port 123.

That would be a very usefull change, IMHO.

>> Second, rather than using clock_gettime() and adjtime() it will use
>> calls that modify a second clock which is implemented in the Linux
>> kernel.
>
> For my purposes, a test unprivileged ntpd would modify a fictional
> system clock composed within ntpd using the real system clock modified
> by frequency and offset changes which normally would be applied to the
> system clock.  This is a trickier bit of code to get right than the
> UDP port change.

Ugh, that does indeed sound a bit hairy. But if it is only for test
purposes a naive approach might be enough?

> I'm curious how your second clock would be used, and what mechanism
> might be used to let you cleanly intercept the clock-affecting calls
> without requiring local patches to the NTP code.

I will apply local patches to use a custom system call. As far as I
can see I just need to replace clock_gettime() and adjtime() with my
custom versions.
The idea is to have have the clock tick in the kernel controlling two
clocks, each with their own value and frequency.
Exactly how this is implemented, I do not yet know. A college of mine
seems to know what he will be doing, and I'll just give that a spin
:-)


> Your patch missed a questionable bit of code I coincidentally am
> likely to remove from ntpq-subs.c do_printpeers() line 1571:
>
>        /*
>         * Check to see if the srcport is NTP's port.  If not this probably
>         * isn't a valid peer association.
>         */
>        if (havevar[HAVE_SRCPORT] && srcport != NTP_PORT)
>                return (1);
>
> Remove that code and your ntpq should be much happier.  It appears to
> have been added as a sanity check, but it's not a very good one.

Ahh, yeah, I missed that one. Removed it, and now it seems to work.
Thank you very much for the help.

Cheers,
Paul



More information about the questions mailing list