ntpd sementation fault using NMEA driver

Just to add, if I try gtkterm I can open and see the NMEA messages just fine, so I don't know why it should report "refclock_open /dev/gps0: Permission denied" in the first place.

If I remove the symlink, it works but without the GPS (as one might reasonably expect) and this is the corresponding syslog message:

Jun 18 17:59:02 pscpc ntpd[3075]: refclock_open /dev/gps0: No such file or directory
Jun 18 17:59:02 pscpc ntpd[3075]: configuration of 127.127.20.0 failed

So it looks as if a failed open is occuring, and that is crashing ntpd with a segmentation fault. What is not clear is why the two type of failed open should differ, and why it can't open /dev/gps0 while gtkterm seems happy enough to do so.

Thank you for opening this bug and helping make Ubuntu better.

Your issue seems to be related to this apparmor message:

Jun 18 17:33:33 pscpc kernel: [18794.490995] type=1503 audit(1276878813.771:19): operation="open" pid=2889 parent=1 profile="/usr/sbin/ntpd" requested_mask="rw::" denied_mask="rw::" fsuid=0 ouid=0 name="/dev/ttyS0"

So you probably need to edit /etc/apparmor.d/usr.sbin.ntpd to add this capability.

Nevertheless, I do agree ntpd should not die a most horrible death because of that. Unfortunately, we do not have a stacktrace to look at. Can you please provide us with one?

FYI-- rather than updating the AppArmor profile, you should adjust /etc/apparmor.d/tunables/ntpd instead, which has a setting for people to adjust the ntpd device.

Yes, the problem starts with the apparmour protection system not knowing it should be allowed serial port access. However, I tried to edit /etc/apparmor.d/tunables/ntpd to change the line to:

@{NTPD_DEVICE}=/dev/ttyS0

then restarted /etc/init.d/apparmor but that did to help, however, adding this to the /etc/apparmor.d/usr.sbin.ntpd file:

/dev/ttyS0 rw,

then restarting /etc/init.d/apparmor did work.

So first question is what is the correct entry in /etc/apparmor.d/tunables/ntpd needed to do it the preferred way?

The next observation is that rendering the serial port theoretically unusable by:

sudo chmod 000 /dev/ttyS0

Produced similar, but not quite identical results:
Jun 21 12:36:08 pscpc ntpd[8089]: ntpd 4.2.4p8@1.1612-o Fri Apr 9 00:28:40 UTC 2010 (1)
Jun 21 12:36:08 pscpc ntpd[8090]: precision = 1.000 usec
Jun 21 12:36:08 pscpc ntpd[8090]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #1 wildcard, ::#123 Disabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #2 vmnet8, fe80::250:56ff:fec0:8#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #3 lo, ::1#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #4 vmnet1, fe80::250:56ff:fec0:1#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #5 eth0, fe80::213:20ff:fecb:72d6#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #6 lo, 127.0.0.1#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #7 eth0, 134.36.22.24#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #8 vmnet1, 192.168.227.1#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: Listening on interface #9 vmnet8, 192.168.154.1#123 Enabled
Jun 21 12:36:08 pscpc ntpd[8090]: kernel time sync status 2040
Jun 21 12:36:08 pscpc ntpd[8090]: frequency initialized -1.256 PPM from /var/lib/ntp/ntp.drift
Jun 21 12:36:08 pscpc ntpd[8090]: refclock_open /dev/gps0: Permission denied
Jun 21 12:36:08 pscpc kernel: [ 4642.663943] type=1503 audit(1277120168.659:117): operation="capable" pid=8090 parent=1 profile="/usr/sbin/ntpd" name="dac_override"
Jun 21 12:36:08 pscpc kernel: [ 4642.664223] ntpd[8090]: segfault at 0 ip 0043e7bc sp bfa3f650 error 4 in libc-2.11.1.so[40e000+153000]

But now the oddest part, if I stop apparmor there is no problem, and stranger still it is *working* to read the serial port that is apparently unusable for read or write:

paul@pscpc:~$ ls -l /dev/ttyS0
c--------- 1 root dialout 4, 64 2010-06-21 12:41 /dev/ttyS0

Why/how it is overriding the permission setting is not clear.

My final question is how do I get a stack trace?

I have seen instructions on how to use gdb, but if I try to run the ntpd program with gdb using the same command line as the running daemon is (from ps -Af) it says the program terminated normally, which is clearly not the case as it still shows the segmentation happening fault in the syslog file.

Looking at the /etc/apparmor.d/usr.sbin.ntpd file it seems that any @{NTPD_DEVICE} device is added as read-only, but most of the GPS like things I have seen using serial ports are subject to writing to configure and/or poll them for the time. Will raise that as another bug...

Is the segmentation-fault induced death of ntpd the expected result of apparmor intervention?

If so then I guess this bug is closed with the bug #596859 closure fixing (hopefully) the apparmor profile.