Hacker News new | ask | show | jobs
by cjbillington 798 days ago
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.
2 comments

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

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.

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.