Bug 745709 - chrony does not start on system boot
Summary: chrony does not start on system boot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: chrony
Version: 16
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-13 07:23 UTC by Michael Weidner
Modified: 2019-03-11 08:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-08 16:34:45 UTC
Type: ---


Attachments (Terms of Use)

Description Michael Weidner 2011-10-13 07:23:52 UTC
Description of problem:

When using

bindaddress a.b.c.d
bindcmdaddress a.b.c.d

in the chrony.conf to bind chrony only on my local eth device with address a.b.c.d, chronyd does not start at system boot, systemctl reports:

systemctl status chronyd.service
chronyd.service - NTP client/server
          Loaded: loaded (/lib/systemd/system/chronyd.service; enabled)
          Active: failed since Thu, 13 Oct 2011 07:57:08 +0200; 21min ago
         Process: 876 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=1/FAILURE)
         Process: 802 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/chronyd.service

Starting chronyd.service when system boot has finished manualy at the command prompt does work as expected.

When removing bindaddress and bindcmdaddress from the chrony.conf file it starts again at system boot.

Version-Release number of selected component (if applicable):

chrony-1.26-3.20110831gitb088b7.fc16.i686


How reproducible:

At everey system boot.


Steps to Reproduce:

1.add bindaddress a.b.c.d and/or bindcmdaddress a.b.c.d to chrony.conf
2.reboot system

Actual results:

chronyd.service fails to start at system boot

Expected results:

chronyd.service is running after a system boot

Comment 1 Miroslav Lichvar 2011-10-13 10:18:45 UTC
To be able to bind to a specific network address, the interface has to be up before the chronyd process is started. There doesn't seem to be a clean way how to specify this in the unit file. After=network.target will only wait for the NetworkManager service, not the actual network interfaces.

You can try to force it to sleep for a fixed time

ExecStartPre=/bin/sleep 10

Comment 2 Michael Weidner 2011-10-13 10:42:10 UTC
This seems to work as a workaround.

Wouldn't it be possible to do something like this in the /usr/libexec/chrony-helper if bindaddress or bindcmdaddress is present in the chrony.conf?

Otherwise I havo to change or check the unit file manualy every time chrony is updated by yum.

Comment 3 Miroslav Lichvar 2011-10-13 12:31:13 UTC
There are other commands that won't work if started before network, e.g. initstepslew. Also some commands may need working DNS, this could be tricky.

I think instead of adding hacks to each service which needs this, it should be handled by NM and provide a target that will wait for a real interface (one with default route?).

To avoid the problem with updated package, you can keep a locally modified unit file in /etc/systemd/system.

Also, please note that with bindcmdaddress set to an eth address, local chronyc won't be able to communicate with chronyd and the logrotate script will fail. Perhaps setting it to 127.0.0.1 and ::1 would preferable.

Comment 4 Miroslav Lichvar 2011-11-08 16:34:45 UTC
Apparently there is a NetworkManager-wait-online.service which can be enabled to wait (up to 30 seconds) for a real network and services which have After=network.target will be started after that. It uses

ExecStart=/usr/bin/nm-online -q --timeout=30

which I think can be used directly in the chrony service file as ExecStartPre if you don't want to enable the wait-online service.

I'm closing this bug as WONTFIX as there is not much we can do. The default service file works with the default chrony.conf, but some options require a modified service.


Note You need to log in before you can comment on or make changes to this bug.