Hide Forgot
Description of problem: ntp starts before the network is available. Version-Release number of selected component (if applicable): ntp-4.2.6p5-22 How reproducible: Every time Steps to Reproduce: 1. boot the server Actual results: The network is coming up after ntp starts. Expected results: That ntp starts after the network. Additional info: So the journal are full with: ntpd_intres[3379]: recv() fails: No route to host only an systemctl restart ntpd will stop the flood and get ntpd back to working. temporary fix: create /etc/systemd/system/ntpd.service.d/network.conf with the content: [Unit] After=network.target syslog.target ntpdate.service sntp.service
I ran into this problem. The ntpd service has no dependency on network or NetworkManger service. However, it does have dependency on ntpdate which further depends on network service. ntpdate is not enabled by default. On boot up (with only ntpd enabled), the boot order is wrong with ntpd loads before network service: http://vagarwal.net/f/systemd-analyze_plot-problem.svg If one enables ntpdate service, the boot order is fixed and problem is resolved: http://vagarwal.net/f/systemd-analyze_plot-fixed.svg
The ntpd service doesn't wait for network, because ntpd can be useful without network (e.g. with reference clocks) and also to not delay restoring the frequency of the system clock from the driftfile. I don't see any recv() errors reported by ntpd in my log, just deferred resolving of hostnames. Can you please post your ntp.conf?
It will only contains this lines: server foo.server server bar.server server xxx.server
(In reply to Frank Büttner from comment #0) > So the journal are full with: > ntpd_intres[3379]: recv() fails: No route to host This error indicates the resolving process of ntpd is not able to connect to 127.0.0.1. Does the loopback interface have an unusual configuration, e.g. no IPv4 address?
No, it looks normal: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
Interesting. I'm assuming ntpd is configured to listen on all interfaces (which is the default). Does the following command work for you? # ntpdc -c authinfo 127.0.0.1
It will result in: ntpdc -c authinfo 127.0.0.1 time since reset: 150 stored keys: 1 free keys: 11 key lookups: 9 keys not found: 1 uncached keys: 2 encryptions: 0 decryptions: 4 expired keys: 0
Hm, I'm running out of ideas. There is only one report for this error, so it's most likely something specific to the configuration of the machine. I'm not sure how useful this will really be, but can you please consider running ntpd in strace and posting the logs? If you change the ExecStart line in the ntpd unit file to /usr/bin/strace -ff -ttt -o /tmp/ntpd.strace /usr/sbin/ntpd -u ntp:ntp the logs should be saved in /tmp/systemd-private-*-ntpd.service-*/tmp.
Created attachment 1272853 [details] The stack traced. I have create the stack strace. I hope it will help.
Thanks. Except the recv() error, I don't see anything wrong in the logs. The main ntpd process is bound to 127.0.0.1:123 as expected. The name resolving process is trying to send messages to that port, but for some reason it fails and the main process doesn't get any messages. Maybe it is an issue with firewall configuration? If there was a rule using the owner match, it might explain why ntpq/ntpdc can connect to ntpd, but ntpd itself cannot. Does it work when firewall is disabled?
firewalld is not used here. Only iptables, an for the lo interface, all traffic is allowed.
Even ntpdate can fail because it can start before the network is up: Jun 26 15:36:12 aspen ntpdate[641]: Can't find host ntp.cora.nwra.com: Name or service not known (-2) Jun 26 15:36:23 aspen systemd: Reached target Network is Online. It should have After=network-online.target instead of network.target, see https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Ah, I see. /usr/libexec/ntpdate-wrapper keeps trying until the network is up. Seems like that is just a work around though. Sorry to hijack this report - thought it was more pertinent initially.
Feel free to reopen with reproducer.