ntpd error: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING

Question

I have a problem.
Time on server not synchronized.
And it seems that this problem was appear after I set my rules for iptables, which I described here May be I'm wrong and these two events are not related...

CentOS 7.1
ntpd 4.2.6p5

/var/log/messages

May 25 16:48:49 CentOS-70-64-minimal ntpd[26771]: ntpd [email protected] Sat Dec 20 02:38:09 UTC 2014 (1)
May 25 16:48:49 CentOS-70-64-minimal ntpd[26771]: proto: precision = 0.046 usec
May 25 16:48:49 CentOS-70-64-minimal ntpd[26771]: 0.0.0.0 c01d 0d kern kernel time sync enabled
May 25 16:48:49 CentOS-70-64-minimal ntpd[26771]: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING

ntp.conf

driftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1 
restrict ::1
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
disable monitor
server ntp1.hetzner.de iburst
server ntp2.hetzner.com iburst
server ntp3.hetzner.net iburst

EDIT
netstat -lanp | grep ':123'

udp        0      0 5.9.152.9:123           0.0.0.0:*                           24483/ntpd          
udp        0      0 127.0.0.1:123           0.0.0.0:*                           24483/ntpd          
udp        0      0 0.0.0.0:123             0.0.0.0:*                           24483/ntpd          
udp6       0      0 2a01:4f8:190:4008:::123 :::*                                24483/ntpd          
udp6       0      0 fe80::3285:a9ff:fee:123 :::*                                24483/ntpd          
udp6       0      0 ::1:123                 :::*                                24483/ntpd          
udp6       0      0 :::123                  :::*                                24483/ntpd

EDIT 2

This problem became more shadow for me...

service ntpd status

Redirecting to /bin/systemctl status  ntpd.service
ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled)
   Active: inactive (dead)

systemctl list-unit-files | grep 'ntp'

ntpd.service                            disabled
ntpdate.service                         disabled

netstat -nlap | grep 'ntpd'

udp        0      0 5.9.152.9:123           0.0.0.0:*                           3588/ntpd           
udp        0      0 127.0.0.1:123           0.0.0.0:*                           3588/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           3588/ntpd           
udp6       0      0 2a01:4f8:190:4008:::123 :::*                                3588/ntpd           
udp6       0      0 fe80::3285:a9ff:fee:123 :::*                                3588/ntpd           
udp6       0      0 ::1:123                 :::*                                3588/ntpd           
udp6       0      0 :::123                  :::*                                3588/ntpd           
unix  2      [ ]         DGRAM                    34224    3588/ntpd  

How it can listen port if ntpd disabled....

Solution

Based on information you provided (specifically the output of the first EDIT: "netstat -lanp | grep ':123'" and second EDIT: "netstat -nlap | grep 'ntpd'"), it's clear that:

• at the time of the first edit:

  • your system were running a process with PID 24483;
  • such process declared itself as named "ntpd";
  • such process bound to UDP port 123 for several IPv4 and IPv6 addresses;

• at the time of the second edit:

  • your system were running a process with PID 3588;
  • such process declared itself as named "ntpd";
  • such process bound to UDP port 123 for several IPv4 and IPv6 addresses;

Under normal conditions (like the ones I'm confident you're experiencing) this means that you are already running an "ntpd" process, and as one ntpd is already running, you cannot launch a new one (or, better, if you launch a new ntpd instance, it will refuse to start simply 'cause it will be unable to get control of needed resources (UDP port 123)).

So, as a general rule, before launching a new "ntpd", please ensure that no other instance is running (...by executing suggested ss/netstat commands and checking results).

As for your final comment -- "How it can listen port if ntpd disabled" -- please note that running/not-running and enabled/disabled are two very distinct concepts and:

• it's perfectly possible to have running processes that are not boot-enabled (...tipically 'cause you launched them manually, after the boot finished its initial running sequence);

• it's perfectly possible that a process/service, scheduled to be boot-enabled (and, as such, tipically lanched during the boot-sequence) is not running (...tipically 'cause you have manually stopped it after the boot or it stopped by itself for a plenty of reasons).

So, back to your (not-very-explicit) question:

• you're unable to launch ntpd 'cause it's already running;

• if you want to launch it again, please ensure to stop it before;

• if you want/don't_want it to be launched at boot-time, please ensure it's "enabled"/"disabled" (according to your distribution-specific approach);

• if you're having problems keeping your time "in-sync", please provide as much details as possible regarding your "ntpd" process (grep ntpd /var/log/messages , as a first start) and the firewall configuration you mentioned to have been applied/changed.

Comments

[Michael Hampton]

Why did you install ntpd? By default chrony is the NTP daemon in RHEL 7 and it is probably already running.

[Valentin Bajrami]

You might check what's keeping port 123 busy using lsof -i :123

[mvillar]

Do an # ss -tlpn and show us the output. PS: Use ss instead of netstat, netsat is now deprecated by Red Hat

[Valentin Bajrami]

@SergeySerov port 123 is being used by httpd so that port is already used. I thought you figured that out

[Sergey Serov]

Thank You very much for Your detailed help!! I research this problem deeper and find that one script in cron use ntpd command, and after it 'service ntpd status' failed and 'service ntpd start' fails too. Only after kill process it is became possible to run 'service ntpd start'.