Comment 5 for bug 805661

I added the following to /etc/apparmor.d/usr.sbin.ntpd

/var/log/ntp/ntp.log rw,
/var/log/ntpstats/clockstats rw,
/dev/oncore.serial.0 rw,
/dev/oncore.pps.0 r,

It will not create the log file in /var/log/ntp. But it will do it in /var/log even with the above changes. When I run ntp configured to create the log file in /var/log I get the following:

 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: refclock_open /dev/oncore.serial.0: Permission denied
 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: 127.127.30.0 interface 127.0.0.1 -> (none)
 6 Jul 13:44:07 ntpd[2220]: running in unprivileged mode disables dynamic interface tracking

The PPS stuff is correctly configured and is running although I have not fully automated it's startup and am starting it by hand. Testing this with:

testpps /dev/pps0

or

testpps /dev/oncore.pps.0

I get the correct results showing that the PPS system is active and that the correct interrupts are being generated.

Also from past experience I know that running ntp in microsecond mode against a nanokernel will result in fairly poor timekeeping. With everything in NANO mode this setup should keep the clock synced to with in 2 microseconds of UTC worst case and most of the time it should maintain offsets that are less than 1 microsecond. But with ntp in micro mode and a nanokernel my experience has been that offsets will get as high as 100 microseconds and the clock will be unstable and poorly synced. This is not apparent when using Internet based time servers since time errors are typically 3 orders of magnitude greater than we expect to see with a local high precision reference clock (IE. milliseconds vs. microseconds) and jitter is also in the milliseconds range where I expect to see 1 microsecond jitter levels with this setup.