I encountered an issue after installing NTP on a VM running CentOS 5.5. (I installed it using the standard "yum install ntp".) When I attempted to start NTP, it would fail to sync with the NTP servers, but seemed
to start ok. If I checked its status, though, I would see that there was a dead PID file in /var/run, and that it wasn't actually running.
Checking the /var/log/messages file, I would see this each time I attempted to start it.
Jun 5 03:46:25 cent01 ntpdate: cap_set_proc failed.
Jun 5 03:46:25 cent01 ntpd: ntpd firstname.lastname@example.org Sat Dec 19 00:56:13 UTC 2009 (1)
Jun 5 03:46:25 cent01 ntpd: precision = 1.000 usec
Jun 5 03:46:25 cent01 ntpd: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface wildcard, ::#123 Disabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface lo, ::1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface lo, 127.0.0.1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface venet0, 127.0.0.1#123 Enabled
Jun 5 03:46:25 cent01 ntpd: Listening on interface venet0:0, [MY SERVER IP]#123 Enabled
Jun 5 03:46:25 cent01 ntpd: kernel time sync status 0040
Jun 5 03:46:26 cent01 ntpd: cap_set_proc() failed to drop root privileges: Operation not permitted
I did some Googling, and tried a couple of things.
- Uninstalled and reinstalled ntpd.
- Updated the libcap package.
- Temporarily disabled iptables. Verified nothing was blocking port 123.
- Verified connectivity to NTP servers.
I eventually ran across a post that alluded to the /etc/sysconfig/ntpd file, one that I hadn't touched yet. Taking a look at that, I saw this at the top.
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
This seemed to match the error I was seeing in the messages file. For grins, I commented this line out and attempted to start NTP. It sycned and fired right up. The resulting PID file is also owned by root, as would be expected as a result of commenting out that line.
My question is this. I feel like my workaround is sort of a band-aid, and probably not the most secure solution. This is a personal server, so if something happens to it, it's not really a huge deal. For my own understanding, though, I'd like to get a better understanding of this, and see if anyone has encountered this issue before, or has a better solution. Various articles and threads I have read allude to various "kernel bugs" and things of this nature, but nothing specific is ever mentioned.
Here are the relevant stats.
[root@cent01 run]# cat /etc/redhat-release
CentOS release 5.5 (Final)
[root@cent01 run]# uname -a
Linux cent01.xxxxxxxxx.net 2.6.18-028stab068.9 #1 SMP Tue Mar 30 17:22:31 MSD 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@cent01 run]# rpm -qa | grep ntp
[root@cent01 run]# grep ntp /etc/passwd
[root@cent01 run]# cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
#OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid"
# Set to 'yes' to sync hw clock after successful ntpdate
# Additional options for ntpdate
[root@cent01 run]# cat /etc/ntp.conf
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict -6 ::1
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#broadcast 192.168.1.255 key 42 # broadcast server
#broadcastclient # broadcast client
#broadcast 220.127.116.11 key 42 # multicast server
#multicastclient 18.104.22.168 # multicast client
#manycastserver 22.214.171.124 # manycast server
#manycastclient 126.96.36.199 key 42 # manycast client
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
# Specify the key identifiers which are trusted.
#trustedkey 4 8 42
# Specify the key identifier to use with the ntpdc utility.
# Specify the key identifier to use with the ntpq utility.
[root@cent01 run]# cat /etc/ntp/step-tickers
If anyone has any thoughts, or has seen this before, your feedback would be most appreciated.