[Improvement idea] Lack of post-stop chrony control in sfptpd service

[sasharozenson]

When running sfptpd alongside chrony, there’s a risk that chrony's clock control state may remain altered if sfptpd fails or crashes. Without specific commands to reset chrony's state after a failure, chrony may continue to operate in an unintended state, potentially affecting the clock.

Suggested Improvement

To address this, I propose adding an ExecStopPost command to the sfptpd.service file. This will ensure that if sfptpd stops unexpectedly, chrony’s state will be reset as needed.

ExecStopPost=/usr/libexec/sfptpd/chrony_clockcontrol.py enable

[abower-amd]

Thanks for the helpful suggestion!

The idea was that the save and restore verbs would be used in this sort of situation rather than enable or disable so that the initial state is restored, whatever that was. However, this is still not ideal.

With sfptpd-3.8.0 the clock control has been brought into the daemon and now works differently: it adds a section to the chrony environment file which is identified as an sfptpd addition that can then be wiped out when sfptpd restarts. This means that there is no ambiguity about what the sysadmin had in mind as being the normal state.

sfptpd/src/crny/sfptpd_crny_helper.c

Lines 176 to 177 in cd01ab8

	#define START_BLOCK "### BEGIN sfptpd ###"
	#define END_BLOCK "### END sfptpd ###"

I can still see this is a problem if sfptpd crashes out and never gets restarted but perhaps this reduces the urgency of mitigation?

[abower-amd]

P.S. we really wish chronyd offered runtime control of whether it is disciplining the system clock, like ntpd does. That would be much more robust!

[sasharozenson]

Aha, I see, thanks!

I'll look into using save/restore as you suggested. Currently, we don't auto-restart sfptpd on failure, so adding the systemd command seems helpful [in our case].

[abower-amd]

I wouldn't necessarily say the issue is closed - it is a good point! Though we'd have to make sure it was also clean for non-chrony users.

Another option we have up our sleeves is to supervise the chronyd process directly (not via systemd) using the new sfptpd privileged helper. I think this might be how chronyd is controlled by the 'timemaster' tool, too, so there would be precedent for doing that. Then there would be no messy environment editing. In that situation you would want sfptpd always running though (via restart) because that would become the way you ran chronyd full stop, and yes, you'd have an interruption of chrony service if sfptpd restarted.

[sasharozenson]

Reopening this issue - it was an oopsie closing it earlier. 😊 I spent some time exploring ways to manage chrony and sfptpd with systemd alone, but nothing quite matches the flexibility of chrony_clockcontrol.py for handling environment-specific changes. I'm not sure about adding another helper process, though, wouldn't that also require something to monitor it as well?

[abower-amd]

Hi @sasharozenson yes, but now we have a new process already - the privileged helper is new in v3.8 to allow sfptpd to drop privileges while still supporting hotplug and chrony control, which wouldn't otherwise be possible.

So it could directly start chronyd rather than editing the sysadmin's config and telling systemd what to do. I think the net result might be more robust because it is explicit about who is responsible for the chrony service - I think really only the sysadmin should call systemctl, not other daemons.

Still, the script option is still available, and you can customize it!

[abower-amd]

I'll look into using save/restore as you suggested.

Does restore work for you? I wouldn't expect to add that by default to the service unit file because people not doing chrony control shouldn't have that sort of thing running but we could maybe include it commented-out.

[sasharozenson]

I’ve decided to keep it as ExecStopPost=/usr/libexec/sfptpd/chrony_clockcontrol.py enable for now. Unfortunately, I don’t recall the exact problem that led to this decision, but I believe it was due to internal linux considerations rather than anything directly related to sfptpd.