3 ms·

The wireguard problem is a pain in the neck. Even if you're happy for your system to not have a realtime clock, when it does come online you'd want wireguard to

The wireguard problem is a pain in the neck. Even if you're happy for your system to not have a realtime clock, when it does come online you'd want wireguard to not start until after the clock has synced to a timeserver. The below is what I'm doing at the moment, but I can't say I'm sure it's working - haven't seen wireguard start before the time is synced since doing it, but it could be probabilistic: systemctl enable systemd-time-wait-sync.service mkdir -p /etc/systemd/system/wg-quick@wg0.service.d/ echo "[Unit] After=time-sync.target Wants=time-sync.target " > /etc/systemd/system/wg-quick@wg0.service.d/override.conf I'd be interested if anyone could let me know if they think this is likely to be achieving what I want or not.

hcfman 2y ago
Well... I see where you are going with this but is it necessary? What happens if the clock gets it's correct time sync back, will not wireguard come back online by itself ? Then the real solution might involve ensuring good clock sync. Using a GPS synched time source is good for this, such as this one :) https://github.com/hcfman/sbts-aru https://github.com/hcfman/sbts-aru
- cjbillington 2y ago
  No, I can't say I understand it fully - but if the clock goes backwards, peers will not talk to a client again until I restart the other peers' wireguard services. No matter if the client's clock is subsequently correct. For some people, all their network access goes over wireguard and that includes time syncing. That's not the case for me, but for those people if wireguard isn't working their clock can't sync. That GPS receiver looks cool! However an RTC and a battery will do just fine for me, which is the plan.
yjftsjthsd-h 2y ago
That was my thought as well - if we know certain things need time to be in sync, can we use systemd dependencies to enforce that? I'm not sure it would help with OP's problem because that was more or less a circular dependency (time sync needed name lookup which needed time to be in sync), but it could mitigate some of the effects or at worst make the problem more explicit/obvious.

hcfman 2y ago

Well... I see where you are going with this but is it necessary? What happens if the clock gets it's correct time sync back, will not wireguard come back online by itself ? Then the real solution might involve ensuring good clock sync. Using a GPS synched time source is good for this, such as this one :) https://github.com/hcfman/sbts-aru https://github.com/hcfman/sbts-aru

cjbillington 2y ago
No, I can't say I understand it fully - but if the clock goes backwards, peers will not talk to a client again until I restart the other peers' wireguard services. No matter if the client's clock is subsequently correct. For some people, all their network access goes over wireguard and that includes time syncing. That's not the case for me, but for those people if wireguard isn't working their clock can't sync. That GPS receiver looks cool! However an RTC and a battery will do just fine for me, which is the plan.

yjftsjthsd-h 2y ago

That was my thought as well - if we know certain things need time to be in sync, can we use systemd dependencies to enforce that? I'm not sure it would help with OP's problem because that was more or less a circular dependency (time sync needed name lookup which needed time to be in sync), but it could mitigate some of the effects or at worst make the problem more explicit/obvious.