CalDAV backend sometimes saves incomplete configuration with Flatpak, preventing app startup

[steveblamey]

Running GTG 0.6 stable flatpak on my Chromebook and using CalDAV sync.

After configuring the backend an initial sync happens and synced task appear as expected. After closing GTG and re-openning, startup fails with the following error:

Context: Startup

Traceback (most recent call last):
  File "/app/lib/python3.9/site-packages/GTG/gtk/application.py", line 110, in do_startup
    for backend_dic in BackendFactory().get_saved_backends_list():
  File "/app/lib/python3.9/site-packages/GTG/backends/__init__.py", line 143, in get_saved_backends_list
    module = self.get_backend(settings.get('module'))
  File "/app/lib/python3.9/site-packages/GTG/core/config.py", line 164, in get
    raise ValueError(
ValueError: No valid configuration value or default value was found for %s in %s

Software versions:

• Getting Things GNOME! v0.6
• CPython 3.9.9 (main, Nov 10 2011, 15:00:00) [GCC 11.2.0]
• GTK 3.24.31, GLib 2.70.2
• PyGLib 3.42.0, PyGObject 3.42.0
• Linux-5.4.163-17384-g99ca1c60d20c-aarch64-with-glibc2.33

Inspecting the backend.conf I notice that a number values are missing or incorrect (see below). Adding and correcting also causes startup to fail because the password had not been stored.

...
[backend_caldav]
first_run = True
default = False
human-friendly-name =
user =
pid = 58a617ea-7590-41ff-8bfa-58ec6c5f83de
enabled = True
attached-tags = gtg-tags-all
period = 1
username = steve

[nekohayo]

I'm puzzled as to how anyone who tested that feature so far had not run into that issue... could it be that there is something special about your password/passphrase (or something else) that breaks saving the data? Have you been able to unbreak it (by clearing that corrupt configuration, I suppose) and looking at the debug output (might be worth trying it out with the debug option of launch.sh in the git version) to see if there's some sort of warning or error going on at the time of the initial activation?

Just wildly guessing and prodding for initial info here, @jaesivsm and others would most likely have a much better idea of how to troubleshoot this :)

[steveblamey]

I managed to install the development version on the Chromebook to try and replicate this issue. CalDAV syncing worked once I had established that libsecret needed to be installed to enable the CalDAV backend to save a password.

This issue seems to be related to the flatpak on the Chromebook. Possibly related to the VM/lxc container set-up on ChromeOS.

[steveblamey]

@nekohayo Just typing an update as you posted. This looks to be specific to the Flatpak on Chromebook.

[steveblamey]

Running gtg from the Chromebook terminal

flatpak run org.gnome.GTG

I get the following error on closing the app, after setting up CalDAV sync:

2022-03-06 07:16:30,129 - WARNING - adaptive_button:do_forall:279 - Got error in for but it should've stay valid: AttributeError("'AdaptiveFittingWidget' object has no attribute '_children'")
Traceback (most recent call last):
  File "/app/lib/python3.9/site-packages/GTG/gtk/application.py", line 647, in do_shutdown
    self.req.save_datastore(quit=True)
  File "/app/lib/python3.9/site-packages/GTG/core/requester.py", line 269, in save_datastore
    return self.ds.save(quit)
  File "/app/lib/python3.9/site-packages/GTG/core/datastore.py", line 634, in save
    value = b.cast_param_type_to_string(param_type, value)
  File "/app/lib/python3.9/site-packages/GTG/backends/generic_backend.py", line 434, in cast_param_type_to_string
    return str(Keyring().set_password(
  File "/app/lib/python3.9/site-packages/GTG/core/keyring.py", line 49, in set_password
    result = Secret.password_store_sync(
gi.repository.GLib.GError: g-dbus-error-quark: org.freedesktop.DBus.Error.ServiceUnknown (2)

(gtg:2): GLib-GIO-CRITICAL **: 07:16:30.376: GApplication subclass 'GTG+gtk+application+Application' failed to chain up on ::shutdown (from end of override function)

[diegogangl]

And libsecret is installed right? I wonder why flatpak would not be able to access it

[steveblamey]

Yes, libsecret installed and proved to be working by running the development version with launch.sh.

Here is the journal error concurrent with the issue seen in the GTG flatpak app:

Mar 07 13:07:48 penguin xdg-desktop-por[654]: Backend call failed: GDBus.Error:org.freedesktop.DBus.Error.Failed: Collection login doesn't exist

I don't know if that is related.

[nekohayo]

@steveblamey maybe you can use flatseal to investigate if it's a permissions issue?

[diegogangl]

Sorry for the delay, I can confirm this doesn't happen in the flatpak version in Fedora. It's definitely saving and restoring ok.
Looks like this might be a chromebook+flatpak issue

[steveblamey]

After more investigation I've discovered that the  root cause is that the keyring is not being unlocked. On a Linux desktop the user's keyring is unlocked on login, but that doesn't happen on the Linux container under Chrome OS. As is often the case, the Arch Wiki comes to the rescue and explains how to add a user systemd unit that prepares the gnome keyring daemon when the container starts; https://wiki.archlinux.org/title/Chrome_OS_devices/Crostini#Unlock_the_keyring_when_starting_the_container That solves the problem. I will add some additional comments later.

[steveblamey]

Thanks to @diegogangl and @nekohayo for help and encouragement to track down the cause of this issue. The TLDR answer is above, #845 (comment).

Motivation

I run GTG on my laptop, which is powered by fedora. This is great but creates a sort of task management island that I can only visit when I have my laptop around. CalDAV sync is a game changer enabling me to collect tasks on my Android phone and also run GTG in the Linux environment on my Chromebook and have tasks synced back to other devices!

I'm using an HP X2 11, which is an ARM based convertible Chromebook with detachable keyboard/trackpad. The CalDAV service for testing is Radicale.

Notes on testing with the development version

While investigating this issue I used the development version of GTG to do some testing. After starting the app for the first time and configuring the CalDAV backend;

• Tasks sync as expected
• On closing the app:
  • The backend.conf is populated successfully
  • A password for the CalDAV service is added to the keyring

When starting GTG again the password is retrieved and the CalDAV backend connects and syncs successfully.

After restarting the lxc container and running GTG, I was asked for a password to unlock the keyring. GTG then fails to retrieve the CalDAV password from the keyring (possibly a timing issue due to a sync call?), the CalDAV backend is called but fails to authenticate with the service. Auth failure would be expected but, checking the keyring, the stored password was now blank!

It seems that the CalDAV backend was able to access the keyring some fraction of a second after startup and calls Secret.password_store_sync, which stores a new password (empty string).

How it looks when using the flatpak

I understand that access to the keyring is mediated by xdg-desktop portal in flatpak. In this case there is no prompt for a password to unlock the keyring, the CalDAV backend fails to store the password and, therefore, does not write a full configuration. That leads to the error described in #845 (comment) when GTG is closed and restarted.

Removing the incomplete CalDAV section in backend.conf allows GTG to start without error.

Follow-up

• Is this set-up for GTG on ChromeOS worth documenting somewhere?
• Should there be some more checks in the code to give the user a better idea of what's going on? I realise that I may be the only one on the planet running GTG on ChromeOS 😉.

[diegogangl]

Congrats on figuring it out!

Should there be some more checks in the code to give the user a better idea of what's going on?

A more descriptive error would be nice, though I don't think we can say more than "There's something wrong with libsecret"

Is this set-up for GTG on ChromeOS worth documenting somewhere?

I think so, but I don't know if we have a place for that in the wiki page (https://wiki.gnome.org/Apps/GTG). What do you think @nekohayo ?

[nekohayo]

It might not be only a ChromeOS-related issue, if 877 and 895 (linked above) turn out to be the same problem... if that is indeed the case, then we can rename this ticket here to reflect the cause (the keyring) and the fact that it's not specific to one particular platform, although strangely it seems to manifest pretty rarely (considering we've had only a handful of people report this here, vs thousands of users)...

[ovalenti]

It might not be only a ChromeOS-related issue

I confirm that I had this elsewhere (flatpak in RHEL)

workaround for the flatpak distribution:

As a clue for people hitting this issue and just trying to get the app running again, I could work around it by editing ~/.var/app/org.gnome.GTG/config/gtg/backends.conf and adding module = backend_caldav to the section [backend_caldav]

[nekohayo]

I wonder if this might have had anything to do with issue #846 at some point, or if that's just a coincidence?

[nekohayo]

For anyone looking at retesting, investigating, and potentially fixing this with the latest git master (if not already fixed, but you will have to go through @azmeuk's discovered #998 first), @averyfreeman's #895 had a pretty extensive investigation, worth a look. Help wanted.