Gnome Online Accounts - connection to Nextcloud stops working

I stumbled over this a few times already: contacts or calendar silently not being synchronized.

When I’ve been getting aware of the problem by missing out on something or not having a number I left in my Nextcloud from a different device I look at gnome-control-center to find this situation:

I tap Sign In and have to provide the credentials to log in to my Nextcloud anew. After that the account works again for an unknown time before I stumble over that problem again.

I searched for the problem and found a somewhat old posting describing some background.

Thinking back with this knowledge I remember having restarted phosh.service several times on my Librem5.

Also, my desktop running the same version of PureOS has its gnome-shell crashing from time to time and I stay logged in to the system on a tty to restart the desktop by restarting gdm.service if the crash happened.

The situation is comparable except that the phone is running Phosh and the desktop Gnome.

On both systems there is the same systemd setting that might be related to the probem:

$ systemd-analyze cat-config systemd/logind.conf | grep -i killuserprocesses

Working hypothesis:

  • after restarting the gui on the phone gnome-online-accounts has problems talking to the running gnome-keyring

Does that make sense? And if so, why I’m not running into the same situation on my notebook (or do I not remember correctly the circumstances of the last crash of gnome)?

Any help to solve this would be very much appreciated. Having an up-to-date calendar and phone book is one of the few services on the Librem5 I really need to rely on.


  • checked the status of my Nextcloud account in gnome-control-center: o.k.
  • logged in to my Librem5 via ssh
  • ran systemctl restart phosh
  • checked again my Nextcloud account in gcc: broken as described above
  • via ssh
    • sudo systemctl stop phosh
    • sudo systemctl stop user@1000.service
    • sudo systemctl stop user-1000.slice
    • got disconnected, because systemd shut down my login
  • after reconnect via ssh:
    • checked that neither goa-daemons nor a keyring is running anymore
    • started phosh without having an active login (to avoid anything systemd might have left over for my actual user session) by root@pureos:~# echo /usr/bin/systemctl start phosh | at now+2m and then logging out before the job would start
  • checked again in gcc: Nextcloud account works again

This seems to support the hypothesis that the Nextcould gnome online account stops working when restarting phosh.

purism@pureos:~$ systemctl status `pgrep gnome-keyring`
Failed to get unit for PID 107225: PID 107225 does not belong to any loaded unit.

purism@pureos:~$ systemctl status `pgrep goa-daemon`
● dbus.service - D-Bus User Message Bus
     Loaded: loaded (/usr/lib/systemd/user/dbus.service; static)
     Active: active (running) since Fri 2023-04-21 10:09:01 CEST; 32min ago
TriggeredBy: ● dbus.socket

gnome-keyring doesn’t run under control of systemd, goa-daemon does run under control of systemd. goa-daemon needs to be able to communicate with gome-keyring to get the credentials of an account.

After restarting phosh.service gnome-kearing-daemon is running with a new PID while goa-daemon is still running with the same PID.

The phosh.service unit seems to stop and start gnome-keyring-daemon also. The keyring daemon being stopped and started seems to breakt goa-daemon.


gnome-keyring-daemon seems to be started from /etc/xdg/autostart/gnome-keyring-ssh.desktop when phosh is started via phosh.service (changed the exec= line to test and after restarting phosh the running daemon reflected that change).

Other installations start gnome-keyring-daemon via systemd user service (arch) or via pam (gdm).

I do not know what the root cause of the issue is, but also for me the Nextcloud connection is not stable. I wrote about that before here. In my opinion there should first be an up-to-date evolution-data-server before diving deeper into these issues. The current version on the Librem 5 is 3.38.3-1+deb11u1. The latest upstream version is 3.48.x.

Well, same here. But I came up with the idea that the last time I’ve been accected by this I restarted phosh on my phone beforehand. I can’t say for sure if this has been the cause for that incident, but it is a possible cause, because restarting phosh on the phone reproducibly breaks my Nextcloud gnome-online-account showing me the same error on the gui.

I’ll keep looking into this.

This much I’d say at this point: it seems wrong to me that restarting a service breaks any function. If there is a systemd service it should be designed in a way that stopping and starting it takes care that it will run afterwards the same way not loosing any functionality.

This is not the case with phosh.service. Restarting it breaks my nextcloud account - at least on my phone.

That leaves the following questions:

  • why does it break goa if the gnome-keyring-daemon is restarted?
  • why does’nt gnome-keyring-daemon run as a user service, also?
    • or why doesn’t goa* stuff restart the same way with phosh?
  • how can the integration be changed to make it work?

New information: it stopped working again for me and I looked briefly into it.

I killed goa-daemon and started it anew and got this message:

goa-daemon-Message: 20:25:09.352: /org/gnome/OnlineAccounts/Accounts/account_1611668450_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Invalid password with username “purism” (goa-error-quark, 0): Cannot resolve hostname (goa-error-quark, 4)

I tried to resolve the hostname of my nextcloud and it didn’t resolve. This made me remember that the nameservers used when on mobile connection and sometimes later on a cabled or wifi connection also are not always what I’d expect.

I switched off the modem by hks and tried to resolve my nextcloud servers lan fqdn again: worked.

Looking at gnome-control-center the exclamation mark beside the online account vanished and I got the following message in the window running goa-daemon:

goa-daemon-Message: 20:26:51.320: /org/gnome/OnlineAccounts/Accounts/account_1611668450_0: Setting AttentionNeeded to FALSE because EnsureCredentials() succeded

In this case it seems that the NetworkManage magic didn’t prefer the nameserver provided by dhcp over the lan connection over the one that already had been configured for the mobile connection.

I’d need to look into that…

Update 2023-05-17:

NetworkManager (as set in my Librem5) adds DNS received for a newly activated connection to the end of /etc/resolv.conf.

Leaving connection to my lan leavs as the only nameservers in /etc/resolv.conf the ones of my mobile provider.

Coming back to my lan (connecting to wifi or ethernet through my dock) the nameserver for my lan gets added to the end of /etc/resolv.conf - below the nameserver of my mobile provider.

Trying to resolve the hostname for my nextcloud server the Librem5 asks the first nameserver in /etc/resolv.conf (mobile provider) which answers that the host doesn’t exist.

I’ll try to solve this issue by adding information about nameserver priority or domains the nameserver should be used for on the connection profile for my wifi.

If this doesn’t work I know that it works if dnsmasq is being used to resolve hostnames locally. But I’d prefer not to run another service.