Chronyd

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:

• 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.

  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

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