Description of problem: chronyd.service fails to start for me on my F19. $ systemctl status chronyd.service chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: failed (Result: exit-code) since Thu 2013-07-11 16:15:17 CEST; 5min ago Process: 801 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=1/FAILURE) $ journalctl -b | grep chrony Jul 11 16:15:18 medusa systemd[1]: chronyd.service: control process exited, code=exited status=1 Jul 11 16:15:17 medusa chronyd[826]: chronyd version 1.28-pre1 starting Jul 11 16:15:17 medusa chronyd[826]: Linux kernel major=3 minor=9 patch=9 Jul 11 16:15:17 medusa chronyd[826]: hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2 Jul 11 16:15:17 medusa chronyd[826]: Fatal error : Could not bind IPv6 command socket : Cannot assign requested address Jul 11 16:15:18 medusa systemd[1]: Unit chronyd.service entered failed state. Jul 11 16:15:18 medusa chronyd[801]: Could not bind IPv6 command socket : Cannot assign requested address $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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 2: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:70:5a:88:5b:9c brd ff:ff:ff:ff:ff:ff 3: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether f0:de:f1:f9:b3:9c brd ff:ff:ff:ff:ff:ff inet 10.34.28.147/23 brd 10.34.29.255 scope global em1 valid_lft forever preferred_lft forever inet6 2620:52:0:221d:f2de:f1ff:fef9:b39c/64 scope global dynamic valid_lft 2591940sec preferred_lft 604740sec inet6 fe80::f2de:f1ff:fef9:b39c/64 scope link valid_lft forever preferred_lft forever 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN link/ether 52:54:00:7e:d7:df brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500 link/ether 52:54:00:7e:d7:df brd ff:ff:ff:ff:ff:ff $ sudo /usr/sbin/chronyd -d main.c:355:(main)[11-14:34:53] chronyd version 1.28-pre1 starting sys_linux.c:1022:(get_version_specific_details)[11-14:34:53] Linux kernel major=3 minor=9 patch=9 sys_linux.c:1080:(get_version_specific_details)[11-14:34:53] hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2 cmdmon.c:251:(prepare_socket)[11-14:34:53] Fatal error : Could not bind IPv6 command socket : Cannot assign requested address $ echo $? 1 $ sudo /usr/sbin/chronyd -d -4 main.c:355:(main)[11-14:23:21] chronyd version 1.28-pre1 starting sys_linux.c:1022:(get_version_specific_details)[11-14:23:21] Linux kernel major=3 minor=9 patch=9 sys_linux.c:1080:(get_version_specific_details)[11-14:23:21] hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2 reference.c:180:(REF_Initialise)[11-14:23:21] Frequency -5.582 +/- 2.771 ppm read from /var/lib/chrony/drift ^Cmain.c:439:(main)[11-14:23:29] chronyd exiting Version-Release number of selected component (if applicable): chrony-1.28-0.1.pre1.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. sudo /usr/sbin/chronyd -d Actual results: chrony doesn't start (no matter whether I keep IPv6 connection enabled or disabled) Expected results: chrony starts
From the ip output, it seems the loopback interface doesn't have the ::1/128 address, which chrony tries to bind its command socket to (configured by bindcmdaddress ::1). Removing the directive in the config should fix it, but I'm not sure if we want to that by default. Is it common to not have ::1?
Problem solved, I had net.ipv6.conf.all.disable_ipv6 = 1 in /etc/sysctl.conf. NetworkManager is somehow able to override it, so I was able to get IPv6 address for eth0. If I comment out that line, I receive ::1 and chronyd starts properly. Still, I think chronyd should not crash if IPv6 support is disabled.
Thanks for the update. I agree it should not be a fatal error.
chrony-1.28-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/chrony-1.28-1.fc19
Package chrony-1.28-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing chrony-1.28-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13151/chrony-1.28-1.fc19 then log in and leave karma (feedback).
chrony-1.28-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/chrony-1.28-1.fc18
chrony-1.28-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
chrony-1.28-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I ran into this when checking my systemd logs. While the error is not fatal anymore it still shows up as "red". I have disabled IPv6 on this system and wonder if there is a way to also disable it for chrony to get rid of this non-fatal error.
You can create file /etc/sysconfig/chronyd containing "OPTIONS=-4" to add -4 to the chronyd command line, which will disable IPv6 sockets.