automatic-timezoned doesn't seem to immediately query a location causing the GeoClue service to shutdown and automatic-timezoned to crash

[nogweii]

Describe the bug
automatic-timezoned starts up successfully, and GeoClue gets launched because of the access to the DBus namespace. After 60 seconds of inactivity, GeoClue gets killed by systemd. automatic-timezoned doesn't handle this gracefully, complaining that the remote peer disconnected.

To Reproduce
Launch automatic-timezoned on Arch Linux. Wait a minute.

Expected behavior
Gracefully handling the disconnection and restarting the GeoClue communication.

Logs

Dec 24 14:04:18 mazzie systemd[1]: Starting Location Lookup Service...
Dec 24 14:04:18 mazzie geoclue[11180]: Failed to connect to avahi service: Daemon not running
Dec 24 14:04:18 mazzie systemd[1]: Started Location Lookup Service.
Dec 24 14:04:18 mazzie systemd[1]: Started Automatically update system timezone based on location.
Dec 24 14:04:18 mazzie automatic-timezoned[11191]: [INFO  automatic_timezoned] Starting automatic-timezoned 2.0.43...
Dec 24 14:05:18 mazzie geoclue[11180]: Service not used for 60 seconds. Shutting down..
Dec 24 14:05:18 mazzie systemd[1]: geoclue.service: Deactivated successfully.
Dec 24 14:05:18 mazzie automatic-timezoned[11191]: Error: MethodError(OwnedErrorName("org.freedesktop.DBus.Error.NoReply"), Some("Remote peer disconnected"), Msg { type: Error, serial: 4294967295, sender: UniqueName("org.freedesktop.DBus"), reply-serial: 2, body: Str, fds: [] })
Dec 24 14:05:18 mazzie systemd[1]: automatic-timezoned.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 14:05:18 mazzie systemd[1]: automatic-timezoned.service: Failed with result 'exit-code'.

automatic-timezoned version
2.0.43

Linux distribution

• Name: Arch Linux
• Version: latest (rolling release distro, hooray)

Running geoclue version 2.7.2-1.

Additional context
Looking at the source code, it appears as if it waits for a location update to happen in GeoClue before acting? I think that might not be correct given how GeoClue is configured in this distribution. I was expecting it to immediately trigger a location request to check if the timezone is currently up-to-date.

Running the where-am-i demo does successfully retrieve a location, and the logs look different in that circumstance:

Dec 24 14:01:08 mazzie systemd[1]: Starting Location Lookup Service...
Dec 24 14:01:08 mazzie geoclue[10700]: Failed to connect to avahi service: Daemon not running
Dec 24 14:01:08 mazzie systemd[1]: Started Location Lookup Service.
Dec 24 14:01:09 mazzie geoclue[10700]: Failed to connect to avahi service: Daemon not running
Dec 24 14:01:17 mazzie geoclue[10700]: WARNING:fapi:src/tss2-fapi/ifapi_io.c:339:ifapi_io_check_create_dir() Directory /var/lib/geoclue/.local/share/tpm2-tss/user/keystore does not exist, creating
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR:fapi:src/tss2-fapi/ifapi_helpers.c:1055:create_dirs() mkdir not possible: -1 /var/lib/geoclue/.local/
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR:fapi:src/tss2-fapi/ifapi_helpers.c:1082:ifapi_create_dirs() ErrorCode (0x0006000b) Create directories for /var/lib/geoclue/.local/share/tpm2-tss/user/keystore
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR:fapi:src/tss2-fapi/ifapi_io.c:342:ifapi_io_check_create_dir() ErrorCode (0x0006000b) Directory /var/lib/geoclue/.local/share/tpm2-tss/user/keystore can't be created.
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR:fapi:src/tss2-fapi/ifapi_keystore.c:435:ifapi_keystore_initialize() ErrorCode (0x0006000b) User directory (null) can't be created.
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR:fapi:src/tss2-fapi/api/Fapi_Initialize.c:212:Fapi_Initialize_Finish() ErrorCode (0x0006000b) Keystore could not be initialized.
Dec 24 14:01:17 mazzie geoclue[10700]: WARNING: Listing FAPI token objects failed: "fapi:A parameter has a bad value"
Dec 24 14:01:17 mazzie geoclue[10700]: Please see https://github.com/tpm2-software/tpm2-pkcs11/blob/1.9.0/docs/FAPI.md for more details
Dec 24 14:01:17 mazzie geoclue[10700]: WARNING: FAPI backend was not initialized.
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR: Could not open lock file "//tpm2_pkcs11.sqlite3.lock", error: Read-onlyfile system
Dec 24 14:01:17 mazzie geoclue[10700]: WARNING: ESYSDB backend was not initialized.
Dec 24 14:01:17 mazzie geoclue[10700]: ERROR: Neither FAPI nor ESYSDB backends could be initialized.
Dec 24 14:02:39 mazzie geoclue[10700]: Service not used for 60 seconds. Shutting down..
Dec 24 14:02:39 mazzie systemd[1]: geoclue.service: Deactivated successfully.

[nogweii]

Oh, this is running the geoclue demo agent as I'm using KDE which doesn't have it's own agent implementation like GNOME does.

[maxbrunet]

Hey @nogweii

Looking at the source code, it appears as if it waits for a location update to happen in GeoClue before acting? I think that might not be correct given how GeoClue is configured in this distribution. I was expecting it to immediately trigger a location request to check if the timezone is currently up-to-date.

On startup, automatic-timezoned does immediately request the location when entering the loop. If it does not appear to immediately update the timezone, it is likely that geoclue does not provide the location. The missing piece from all that has been provided would be the GeoClue agent logs, I would check them, ensure it runs as the same user as automatic-timezoned, and is whitelisted in the geoclue config

See also other requirements if needed

After 60 seconds of inactivity, GeoClue gets killed by systemd.

This seems to be the default timeout of geoclue on all platforms, it should keep running as automatic-timezoned registers to receive the location signal. Again I would check that the GeoClue agent is properly configured