Hi there! Thanks for this project, I've been using it for a while now and my timezone setting works flawlessly most of the time.
I have somewhat of an edge case that happens regularly in one of my hosts, so I thought I would open up an issue to help fix it. I have a patch that should hopefully fix this, will open a PR soon.
Describe the bug
If both automatic-timezoned and geoclue start before DNS is available (e.g. if offline), name resolution for geoclue fails, and thus the timezone is not set, which is to be expected.
The problem is that automatic-timezoned enters a state where even when the internet connection is established and/or location is updated, a timezone update is never triggered. automatic-timezoned needs to be restarted for it to start working again.
This is particularly painful if you have a setup where your storage is ephemeral (in my case, NixOS with impermanence), so you get stuck with UTC until you restart automatic-timezoned manually.
To Reproduce
Start up a fresh host without a working internet connection and with the wrong timezone set. Let geoclue and automatic-timezoned start (and fail). Connect to the internet. The timezone will still be wrong until you manually restart automatic-timezoned.
Expected behavior
Timezone should be set after re-establishing an internet connection.
Logs
journalctl -u geoclue -u automatic-timezoned -u dhcpcd:
mar 11 12:34:41 pleione systemd[1]: Starting Location Lookup Service...
mar 11 12:34:41 pleione systemd[1]: Started Location Lookup Service.
mar 11 12:34:41 pleione systemd[1]: Starting Automatically update system timezone based on location...
mar 11 12:34:41 pleione systemd[1]: Started Automatically update system timezone based on location.
mar 11 12:34:41 pleione automatic-timezoned[1674]: [INFO automatic_timezoned] Starting automatic-timezoned 2.0.105...
mar 11 12:34:42 pleione automatic-timezoned[1674]: [INFO automatic_timezoned] Starting loop
mar 11 12:34:42 pleione geoclue[1645]: Failed to query location: Error resolving “api.beacondb.net”: No valid addresses were found
mar 11 12:34:42 pleione dhcpcd[1277]: enp2s0: offered 192.168.0.110 from 192.168.0.1
mar 11 12:34:42 pleione dhcpcd[1277]: enp2s0: probing address 192.168.0.110/24
mar 11 12:34:47 pleione dhcpcd[1277]: enp2s0: leased 192.168.0.110 for 86400 seconds
Note: the "Starting loop" is from a patch I did when debugging:
diff --git a/src/main.rs b/src/main.rs
index f6342c1..bd05a5a 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -57,6 +57,7 @@ fn main() -> Result<(), Box<dyn Error>> {
gclue_client.start()?;
+ info!("Starting loop");
for signal in location_updated {
let args = signal.args()?;
automatic-timezoned version
2.0.105
Linux distribution
- Name: NixOS
- Version: unstable (rolling release)
Additional context
I think a good fix would be for automatic-timezoned to check whether it can get an initial location, and exit with an error if it can't. This way we can let systemd handle restarting it as needed. I have a patch for this, will open up a PR after I test it some more.
Hi there! Thanks for this project, I've been using it for a while now and my timezone setting works flawlessly most of the time.
I have somewhat of an edge case that happens regularly in one of my hosts, so I thought I would open up an issue to help fix it. I have a patch that should hopefully fix this, will open a PR soon.
Describe the bug
If both automatic-timezoned and geoclue start before DNS is available (e.g. if offline), name resolution for geoclue fails, and thus the timezone is not set, which is to be expected.
The problem is that automatic-timezoned enters a state where even when the internet connection is established and/or location is updated, a timezone update is never triggered. automatic-timezoned needs to be restarted for it to start working again.
This is particularly painful if you have a setup where your storage is ephemeral (in my case, NixOS with impermanence), so you get stuck with UTC until you restart automatic-timezoned manually.
To Reproduce
Start up a fresh host without a working internet connection and with the wrong timezone set. Let geoclue and automatic-timezoned start (and fail). Connect to the internet. The timezone will still be wrong until you manually restart automatic-timezoned.
Expected behavior
Timezone should be set after re-establishing an internet connection.
Logs
journalctl -u geoclue -u automatic-timezoned -u dhcpcd:Note: the "Starting loop" is from a patch I did when debugging:
automatic-timezoned version
2.0.105
Linux distribution
Additional context
I think a good fix would be for automatic-timezoned to check whether it can get an initial location, and exit with an error if it can't. This way we can let systemd handle restarting it as needed. I have a patch for this, will open up a PR after I test it some more.