Update openhop-repeater.service to wait on time-sync.target. #146

New Issue

2026-10-27T09:35:25+01:00

adam commented

2026-10-27 09:35:25 +01:00

On cold boot, openHop gets in a race condition with the system syncing time. RPis still don't have an RTC as standard. As such, openHop will report insane uptimes if it starts up before the system has sync'd time over the network. And I was seeing openHop win the race EVERY time on my RPi4b, and thus always had an insane uptime until the service was restarted.

Systemd provides a standard way to fix this, though. Add a dependency on time-sync.target to the openHop unit file.

[Unit]
After=time-sync.target
Wants=time-sync.target

If the user hasn't configured blocking time sync, this is a no-op. The target will fall through immediately.

It is then up to the user to enable the "-wait" service for the time sync daemon they are using. For example, systemctl enable chrony-wait.service. (You ARE using chrony, right? right?) The "-wait" services insert themselves before time-sync.target using a Before= stanza. So if they are enabled, they make dependent units block until first sync. If there isn't one enabled, then as stated, the target just falls through immediately.

Bonus points for the installer script figuring out which time sync daemon the user has running and prompting the user to enable the according "-wait" service. The three main choices are chrony, ntp and systemd-timesync.

On cold boot, openHop gets in a race condition with the system syncing time. RPis still don't have an RTC as standard. As such, openHop will report insane uptimes if it starts up before the system has sync'd time over the network. And I was seeing openHop win the race EVERY time on my RPi4b, and thus always had an insane uptime until the service was restarted. Systemd provides a standard way to fix this, though. Add a dependency on `time-sync.target` to the openHop unit file. ``` [Unit] After=time-sync.target Wants=time-sync.target ``` If the user hasn't configured blocking time sync, this is a no-op. The target will fall through immediately. It is then up to the user to enable the "-wait" service for the time sync daemon they are using. For example, `systemctl enable chrony-wait.service`. (You *ARE* using chrony, right? *right?*) The "-wait" services insert themselves before `time-sync.target` using a `Before=` stanza. So if they are enabled, they make dependent units block until first sync. If there isn't one enabled, then as stated, the target just falls through immediately. Bonus points for the installer script figuring out which time sync daemon the user has running and prompting the user to enable the according "-wait" service. The three main choices are chrony, ntp and systemd-timesync.

adam commented

2026-10-27 09:35:26 +01:00

I have set this up using an override unit for openhop-repeater.service and it is working as expected. But it should just be in the unit file openHop installs, itself.

I have set this up using an override unit for `openhop-repeater.service` and it is working as expected. But it should just be in the unit file openHop installs, itself.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#146