Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More robust logic for gokrazy.WaitForClock #21

Open
Merovius opened this issue Mar 24, 2017 · 1 comment
Open

More robust logic for gokrazy.WaitForClock #21

Merovius opened this issue Mar 24, 2017 · 1 comment

Comments

@Merovius
Copy link

The current logic of WaitForClock isn't particularly robust. If, for whatever reason, the NTP servers aren't reachable for one minute after boot, it will return with an unset time. This doesn't seem unrealistic to me, for example it might take a while after a power outage for the network to come up. It's also not totally harmless; if you use gokrazy for home automation and log data, you'll get nonsensical timestamps in your logs.

I think gokrazy should provide a more robust mechanism to notify for this (and maybe also a successful DHCP leases?). Solution for this could range form simple (ntp updating a file in /tmp when the time was successfully set) to more complex and extensible (init passing a file descriptor for some sort of messaging bus or whatever to child processes).

Let me know if you think this is a good idea and what you would propose.

@stapelberg
Copy link
Contributor

I agree that the current logic is lacking.

With regards to notification mechanisms, I find the solutions currently brought up to either seem unclean (magic files in /tmp) or too complex (custom message bus).

I’m tempted to just keep the current logic, but extend the check to 1 year instead of 1 minute. If users don’t care about their appliance not working for a year, we can safely assume the data isn’t important anyway and corruption is okay. Also, regular software updates should happen more frequently than 1 year.

The 1 year change seems like the simplest solution to me, both because it requires only minimal changes and notably because it doesn’t introduce any new concepts. If we end up with a notification mechanism/message bus at some point, we can always revisit.

Does that sound reasonable?

BTW, the DHCP client currently sends a SIGHUP to init once it acquires a lease, which will then update its listeners if necessary. This is obviously a one-off solution which doesn’t extend to client applications. Thinking about it, DHCP is far from the only way to configure addresses, though: IPv6 autoconf may result in new addresses, and e.g. hot-plugging USB ethernet adapters even more so. Hence, applications which are interested in offering more specific listeners than wildcard listeners (e.g. :80) should monitor network addresses anyway.

Currently, I’m inclined to try to have applications blackbox-monitor the resource in question (e.g. time, network addresses). gokrazy can provide helpers for things which turn out to be common, such as the WaitForClock one we already have. Adding one for network addresses and making init use it would be a welcome improvement.

stapelberg added a commit that referenced this issue Mar 25, 2017
stapelberg added a commit that referenced this issue Nov 1, 2018
bradfitz pushed a commit to bradfitz/gokrazy that referenced this issue Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants