Chronyd - UG1602

sfptpd supports some limited use cases with sfptpd running alongside chronyd. For both daemons to co-exist, only one of them can be allowed to discipline the system clock. Unlike NTP, chronyd does not expose an API that can be used to prevent it from controlling the system clock.

The following use cases are possible. Those provided by more recent versions of sfptpd are preferable:

• From version 3.3.0 onwards, sfptpd has an option to prevent it from disciplining the system clock:

  [general]
  clock_readonly system

  The system clock is then controlled and adjusted by chronyd, but only read by sfptpd.

  For this to work correctly, you must also set the following option:

  [general]
  interface system

  See the clock_readonly option in Configuration Options, and the interface option in Instance-specific Configuration Options.

• From version 3.4.0 onwards, sfptpd supports chronyd as NTP server when either sfptpd or chronyd is statically configured not to discipline the system clock. For example to enable the chronyd and PPS use case, launch chronyd with the -x option.
• From version 3.6.0 onwards, sfptpd has a crny sync module that provides support for operating alongside the chronyd service. An instance of this module is implicitly created by sfptpd. If you do not require this instance, you should disable it by specifying a crny sync module with no instances:

  [general]
  sync_module crny

  This module has an option to specify the path to a script which can be used to enable or disable chronyd clock control:

  [crny]
  control_script /usr/share/doc/sfptpd/examples/chrony_clockcontrol.py

  An example script is supplied, as specified in the previous example.

  See the control_script option in Instance-specific Configuration Options.

  Important: Restarting chronyd is destabilizing for NTP synchronization so this feature should be avoided when the time sync performance of chronyd influences sync instance selection. In the absence of native runtime control for chronyd it is best used in an always-on or always-off mode with sfptpd. If chronyd control is required for fallback it is advisable to give it a lower (numerically higher) priority setting so it is only selected on total failure of PTP, and also to increase the selection_holdoff_period to 60s. Similarly, it is not recommended to use this clock control method while chronyd is operating as a clustering determinant (i.e. as a discriminator).

  Handling of clock control conflicts between sfptpd and chronyd has been improved:

  • If there is a conflict at sfptpd startup because an uncontrollable chronyd service is running, this causes a critical error for sfptpd. This behavior is unchanged, but you can now disable this startup check as follows:

    [general]
    ignore_critical clock-control-conflict

  • If there is a subsequent conflict, sfptpd now allows operation but blocks system clock updates. This is improved behavior when the conflict is transient. It is, however, recommended in such situations to configure sfptpd explicitly to treat the system clock as read only:

    [general]
    clock_readonly system

• From version 3.7.1 onwards, sfptpd has an option to enable or disable chronyd clock control, instead of specifying a path to the helper script:

  [crny]
  clock_control on

  A helper script is still supplied, but is moved to /usr/libexec.

• From version 3.8.0 onwards, sfptpd has a privileged helper so it no longer needs to run as root to control chronyd.

AMD recommends that when NTP functionality is required, chronyd is disabled, and standard NTP or ntpsec is installed.