Bugzilla – Bug 131755
ntp fails to start
Last modified: 2005-11-23 10:00:09 UTC
ntp is failing to start on ia64. I recompiled the version in edge, and still see the same problem. The startup script is running: /usr/sbin/ntpd -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp -i /var/lib/ntp a tail of the strace (which I'll attach) is: 13920 chdir("/var/lib/ntp") = 0 13920 chroot("/var/lib/ntp") = 0 13920 setuid(74) = 0 13920 setresuid(-1, 74, -1) = 0 13920 capget(0x19980330, 0, {0, 0, 0}) = -1 EINVAL (Invalid argument) 13920 capset(0x19980330, 0, {CAP_SYS_TIME, CAP_SYS_TIME, CAP_SYS_TIME}) = -1 EPERM (Operation not permitted) 13920 gettimeofday({1130855423, 577714}, NULL) = 0 13920 write(9, " 1 Nov 08:30:23 ntpd[13920]: cap"..., 100) = 100 13920 munmap(0x2000000000110000, 65536) = 0 13920 exit_group(-1) = ? 31 Oct 11:57:57 ntpd[16381]: cap_set_proc() failed to drop root privileges: Operation not permitted 31 Oct 11:58:26 ntpd[16404]: cap_set_proc() failed to drop root privileges: Operation not permitted 1 Nov 08:27:46 ntpd[13775]: cap_set_proc() failed to drop root privileges: Operation not permitted 1 Nov 08:29:28 ntpd[13846]: cap_set_proc() failed to drop root privileges: Operation not permitted 1 Nov 08:29:53 ntpd[13876]: cap_set_proc() failed to drop root privileges: Operation not permitted 1 Nov 08:30:08 ntpd[13906]: cap_set_proc() failed to drop root privileges: Operation not permitted 1 Nov 08:30:23 ntpd[13920]: cap_set_proc() failed to drop root privileges: Operation not permitted
Created attachment 56131 [details] ntpd strace
Another data point I just thought of ... Erik and I both see this running a current 2.6.14 ia64 kotd from HEAD. Tony says it works fine on his ia64 HP box, and he's running 2.6.13-15.2-default, so it could be a kernel issue with the current kotd.
I've verified that if I run Greg's 2.6.14 kernel on my zx2000 I get the same ntp error. There's no error when I run 2.6.13-15.2-default.
so its a kernel problem...
This is a known problem, the capability kernel module must be loaded.
Dominic, can someone from your team look into this?
any news? this is getting annoying. is there a way to workaround?
You need an updated xntp package (with bug #132236 fixed) plus 'capability' in 'MODULES_LOADED_ON_BOOT' (or something like that) ...
Sorry, I only had this bug assigned to me 2 days ago. modprobe capability (or adding capability to MODULES_LOADED_ON_BOOT in /etc/sysconfig/kernel) allowed nntp to start on ia64 for me. I initially thought that the patch to change default capability behaviour (module not loaded) wasn't in tree, but it seems to be so I need to dig deeper. Bug #132236 seems to be nntp specific and not related to capabilities.
Patch to make capability the default behaviour (CONFIG_SECURITY=yes) rather than dummy isn't in HEAD. It is in SL10 branch (2.6.13). Will update bug once it's back in. In the meantime, just modprobe capability.
OK, I reenabled the patch in CVS, the next kernel that goes out should have this fixed. Tony, I also updated the other LSM patches (which are merely an optimization and a cleanup) but left them disabled for now. Maybe you can have a look.
*** Bug 134591 has been marked as a duplicate of this bug. ***
I tested it, and 'modprobe capability' solved Bug #134591 as well.