Bug 1340203 - goa-daemon (and most other D-Bus services) not stopped when the user session goes away
Summary: goa-daemon (and most other D-Bus services) not stopped when the user session ...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1223117 1338761 1402670 1417806 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-26 17:28 UTC by Mikhail
Modified: 2019-08-19 07:45 UTC (History)
50 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-24 03:07:36 UTC


Attachments (Terms of Use)
screencast (1.72 MB, application/ogg)
2016-05-26 17:28 UTC, Mikhail
no flags Details
screenshot (166.09 KB, image/png)
2016-10-25 19:11 UTC, Mikhail
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 764029 None None None 2019-05-02 19:51:01 UTC

Description Mikhail 2016-05-26 17:28:05 UTC
Created attachment 1162220 [details]
screencast

Description of problem:
Not first time I see message "Failed to authenticate: Failed to obtain an access token for 'mikhail.v.gavrilov@gmail.com':Failed to retrieve credentials from the keyring" then launch evolution.


I don't know why this occurred, but if I reboot machine this problem disappeared.

is it possible to come up something that  this problem did not arise again?

Comment 1 Milan Crha 2016-05-27 06:36:25 UTC
Thanks for a bug report. This error is reported by the gnome-online-accounts, possibly goa-daemon process, thus I'm moving it there. It can be that the libsecret failed to connect to the gnome-keyring for some reason and reports errors. The goa-daemon's console might show it. I see a similar issue from time to time also in the evolution, which uses libsecret too. If it's the same thing, then the root cause can be the libsecret itself.

Comment 2 Dawid Zamirski 2016-06-07 15:09:27 UTC
I can reproduce this by following the steps below:

1. On freshly booted system, start Evolution -> ok
2. Close Evolution
3. Logout (not reboot)
4. Login
5. Start Evolution -> Failed to retrieve credentials from keyring
6. Reboot
7. Start Evolution -> Ok

So this happens to me every time I logout and log back in to the system.

Comment 3 Milan Crha 2016-06-13 09:51:09 UTC
Thanks for the steps. I tried to reproduce this in a Fedora 24 environment and I get the same result. I was also notified about the seahorse-daemon crash right  after the second login (step 4 in your steps above), which can explain why it failed to retrieve credentials. I debugged it further and realized that the goa-daemon doesn't stop on logout, then the login uses the same process, which fails to work with an error:

> ** Message: Remote error from secret service:
> org.freedesktop.DBus.Error.ServiceUnknown: The name :1.10 was not provided
> by any .service files
>
> (goa-daemon.orig:1379): GoaBackend-WARNING **: secret_password_lookup_sync()
> failed: The name :1.10 was not provided by any .service files
> goa-daemon-Message: /org/gnome/OnlineAccounts/Accounts/account_1465808345_0:
> Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Failed
> to retrieve credentials from the keyring (goa-error-quark, 4)

Thus I'd say the problem is that the goa-daemon is not stopped on logout, as other services are, and it reuses a D-Bus connection which is not valid anymore.

Comment 4 Debarshi Ray 2016-06-13 17:04:40 UTC
This sounds like the bug about systemd user sessions not cleaning up daemons after logout. However, I don't have a bug number at hand, so I am unable to mark this is a duplicate.

(On Fedora 24, the D-Bus user session bus is setup by systemd --user.)

Comment 5 Milan Crha 2016-06-14 06:21:48 UTC
Aha, it can be it. I just noticed that neither the evolution-data-server background processes are stopped on logout.

Comment 6 Ivan Shapovalov 2016-06-16 13:38:30 UTC
(In reply to Debarshi Ray from comment #4)
> This sounds like the bug about systemd user sessions not cleaning up daemons
> after logout. However, I don't have a bug number at hand, so I am unable to
> mark this is a duplicate.
> 
> (On Fedora 24, the D-Bus user session bus is setup by systemd --user.)

I would like to note that not stopping `systemd --user` instance after user logout is a perfectly valid scenario, because:

1. there can be multiple overlapping logins of one user (`systemd --user` is stopped when last session terminates);
2. there can be lingering enabled for the user (`loginctl enable-linger`), which makes the user instance live forever.

That said, I do experience this bug every time on current Arch, with versions g-o-a 3.20.1, libsecret 0.18.5, e-d-s 3.20.3. The journal says things like this:

====
intelfx-laptop org.gnome.OnlineAccounts[980]: ** Message: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.9 was not provided by any .service files
intelfx-laptop org.gnome.OnlineAccounts[980]: (goa-daemon:1122): GoaBackend-WARNING **: secret_password_lookup_sync() failed: The name :1.9 was not provided by any .service files
====

Comment 7 Milan Crha 2016-06-17 05:35:13 UTC
(In reply to Ivan Shapovalov from comment #6)
> I would like to note that not stopping `systemd --user` instance after user
> logout is a perfectly valid scenario, because:

Well, it can be valid for `nohup` and similarly run processes, but not for GUI session related (D-Bus) processes, where some outlive other. The error suggests that the goa-daemon survives logout, while the libsecret service, whichever it is, does not, thus the D-Bus connection made by libsecret is invalidated.

Note that also means that the place to workaround this new behaviour is not goa-daemon, but libsecret library, if the new consensus would be that the new behaviour is correct. Still that "some background processes run at GUI login survive and some not" is suspicious.

Comment 8 Ivan Shapovalov 2016-06-17 06:16:44 UTC
The thing is that some processes are started by d-bus activation (as children of user `dbus-daemon` instance and consequently as children of `systemd --user`) in the `systemd --user` scope, and some processes are started as children of `gnome-session-binary` in the session scope.

The latter is always terminated on logout, the former — depends on configuration.

Does it make sense?

Comment 9 Ivan Shapovalov 2016-06-17 06:50:55 UTC
Also it could be that some services started by d-bus activation _do_ maintain a connection to X11 server or to some per-session instance, and other services do not do that.

Hence the former d-bus services will terminate by themselves when the session ends, and the latter will not. And this would not be systemd's or dbus-daemon's fault.

Comment 10 Milan Crha 2016-06-17 06:51:26 UTC
Aha, I see, it makes sense. Thanks. It means, from my point of view, that something doesn't work, like if the transitive dependency on the processes is not properly determined.

I'm not much deep in understanding of the login/logout phases, even less with the systemd, my rough idea, which is most likely wrong, is:

   - user logs in with GUI, like with lightdm, gdm and similar
      - (GUI) user session is started
      - auto-start processes are started, read from /etc/xdg/autostart/
        * these processes can start D-Bus services
        * they have a clear parent, the (GUI) user session
      - some of the D-Bus processes run other D-Bus processes, like
        the evolution processes can request goa-daemon and the goa-daemon
        can request gnome-keyring-daemon and so on
   - user logs out GUI, then everything what was "added" due to GUI run
     applications and daemons should also stop, unless configured to not do that

For me, the systemd --user session starts on login and ends on logout from the GUI, especially if I didn't login anywhere else (like a text console). It can be verified with the lightdm/gdm, that it doesn't ask me whether I want to power off or restart the machine, because other users are logged in, right? Without the prompt, no user systemd session is running, thus all background processes should be stopped, right?

If you mean that the configuration default changed from "stop unless said otherwise" to "keep running unless said otherwise", then it was quite unfortunate decision from the backward compatibility point of view.

In case of the evolution-data-server D-Bus services, there was a change for 3.20.x (Fedora 24), where within bug [1] were added systemd service files, like this one [2], which is installed at /usr/lib/systemd/user/evolution-addressbook-factory.service. It has many values in defaults, as you can see. Does it mean that without those files the evolution-data-server background processes would stop as expected?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=755735
[2] https://git.gnome.org/browse/evolution-data-server/tree/services/evolution-addressbook-factory/evolution-addressbook-factory.service.in

Comment 11 Ivan Shapovalov 2016-06-17 07:21:08 UTC
(In reply to Milan Crha from comment #10)
> Aha, I see, it makes sense. Thanks. It means, from my point of view, that
> something doesn't work, like if the transitive dependency on the processes
> is not properly determined.
> 
> I'm not much deep in understanding of the login/logout phases, even less
> with the systemd, my rough idea, which is most likely wrong, is:
> 
>    - user logs in with GUI, like with lightdm, gdm and similar
>       - (GUI) user session is started
>       - auto-start processes are started, read from /etc/xdg/autostart/
>         * these processes can start D-Bus services
>         * they have a clear parent, the (GUI) user session
>       - some of the D-Bus processes run other D-Bus processes, like
>         the evolution processes can request goa-daemon and the goa-daemon
>         can request gnome-keyring-daemon and so on
>    - user logs out GUI, then everything what was "added" due to GUI run
>      applications and daemons should also stop, unless configured to not do
> that

It was so before session bus turned to user bus. See below.

> If you mean that the configuration default changed from "stop unless said
> otherwise" to "keep running unless said otherwise", then it was quite
> unfortunate decision from the backward compatibility point of view.

Even more than that. I'll try to explain. Initially (before systemd version ≈ 208) there was a separate d-bus bus for each user login, called "session bus". It was started by xinitrc.d scripts and terminated on logout, and it had a pretty obvious lifetime. It was bound to the session — each session had its own set of d-bus services, and they were automatically and implicitly terminated at logout.

Starting with somewhere at that point in time (maybe a bit later), the semantics completely changed: the "session bus" started by xinitrc.d scripts turned to the "user bus" started by `systemd --user`, which is now shared between all login sessions and has wider lifetime:
1) by default, from first login to last logout;
2) optionally, from bootup to shutdown (this is called "lingering" in logind speak).

So, in some terms, the configuration default has changed to "keep running", and I'm not even sure that there _exists_ a standard mechanism to "say otherwise". Moreover, the bus namespace is now shared between all login sessions.

> For me, the systemd --user session starts on login and ends on logout from
> the GUI, especially if I didn't login anywhere else (like a text console).
> It can be verified with the lightdm/gdm, that it doesn't ask me whether I
> want to power off or restart the machine, because other users are logged in,
> right? Without the prompt, no user systemd session is running, thus all
> background processes should be stopped, right?

Not necessarily so. If "lingering" is enabled for a user, then its `systemd --user` instance will keep running from bootup to shutdown.
 
> In case of the evolution-data-server D-Bus services, there was a change for
> 3.20.x (Fedora 24), where within bug [1] were added systemd service files,
> like this one [2], which is installed at
> /usr/lib/systemd/user/evolution-addressbook-factory.service. It has many
> values in defaults, as you can see. Does it mean that without those files
> the evolution-data-server background processes would stop as expected?

No, there is no session bus anymore. If one removes that .service file, it will simply lead to less fine-grained control from systemd side, with no changes in lifetime.

Comment 12 Milan Crha 2016-06-17 08:12:44 UTC
Hmm, okay, let's consider the most common workstation scenario (from my point of view), where is only one user using the machine and that the lingering is turned off by default, only advanced users can enable it, which is not in my case. Then the usual order would be:

   1) boot the machine
   2) gdm is run
   3) log into the gnome-shell from gdb
      - do something useful
      - log out from the gnome-shell
   4) back in gdm

There is exactly one login and exactly one logout.

I tried these steps on a Fedora 24 machine and I did also some other steps around, namely at step 2) and step 4), where I switched to a text console, logged in as a root, run `ps ax | egrep "evol|goa"` and logged out, thus the root is not logged anymore. Running the ps command in step 2) shows no background processes of either of the two. Running it at step 4) shows multiple processes of the both of them.

I'd expect, as the logout before step 4) is the last logout too, the systemd user session processes would be stopped. That's how I understood it from your clarifications too, also because I didn't turn on any lingering here, all is pretty much in default Fedora 24 setup, the systemd part for sure.

Comment 13 Ivan Shapovalov 2016-06-17 08:52:05 UTC
Ugh. I'm on Arch and cannot reproduce, both with KillUserProcesses=yes and no (in logind.conf). I'd expect that too.

On step 4, are there any leftover sessions (loginctl list-sessions) in "closing" state?

Comment 14 Milan Crha 2016-06-17 13:54:36 UTC
(In reply to Ivan Shapovalov from comment #13)
> On step 4, are there any leftover sessions (loginctl list-sessions) in
> "closing" state?

Aha, I tried both at steps 2):
  Session   UID User  Seat
       c1    42 gdm   seat0
        1     0 root  seat0

and at step 4):
  Session   UID User  Seat
        2  1000 mcrha seat0
       c1    42 gdm   seat0
        3     0 root  seat0

Thus you are right that there left the session with 'mcrha', which I just logged out of GNOME shell. The root's session number changes, because I logged in, run the command and then logged out the root in a text console.

Comment 15 Ivan Shapovalov 2016-06-17 15:24:31 UTC
Yeah. What you experience ought to be a separate bug: a session is not closed after logout due to certain leftover processes which fail to terminate. I don't remember the actual bug name or #, but it exists. You can see the offending process(-es) by `loginctl session-status <session id>` at step 4.

So, in fact there are two distinct bugs:
1. sessions not closing;
2. libsecret (IIUC) does not work with goa-daemon on per-user bus as opposed to per-session bus.

...where one of the bugs (1) also happens to be a common reproducer/trigger for the other bug (2). Another reproducer for (2) is to enable lingering mode in logind for the user account.

Comment 16 Ivan Shapovalov 2016-06-17 15:40:11 UTC
...and sorry, the "libsecret does not work with goa-daemon" part apparently is bullshit.

What I really see is that goa reports errors trying to connect to gnome-keyring-daemon, where the former is not terminated on logout and the latter _is_.

So, root cause seems to be this:
1. gnome-keyring-daemon is started by PAM, hence it is bound to the login session (!)
2. when session terminates, gnome-keyring-daemon does so as well
3. goa is on per-user bus, thus it _outlives gnome-keyring-daemon_ and fails to reconnect to the new instance of it.

Comment 17 Debarshi Ray 2016-07-28 13:13:16 UTC
*** Bug 1338761 has been marked as a duplicate of this bug. ***

Comment 18 Debarshi Ray 2016-08-23 14:41:23 UTC
*** Bug 1223117 has been marked as a duplicate of this bug. ***

Comment 19 Mikhail 2016-09-25 20:59:30 UTC
Still not fixed in Fedora 25

Comment 20 Phil Lembo 2016-10-14 21:08:24 UTC
Now failing in Fedora 24 after upgrade from 23, where this worked. This same desktop was upgraded over the two years from Fedora 21 to 22, then from 22 to 23. Wizard appears to work as expected, presenting dialogs for entering user account name, password and 2FA token (I am using Google Authenticator for tokens), and then requesting authorization. Only sign of a problem is the "credentials have expired" warning once returned to accounts list. Same result when attempting to set up Microsoft account.

Comment 21 Phil Lembo 2016-10-15 23:12:09 UTC
Works now. Got update later in the day on 10/14 to dbus and evolution-data packages. Had to reboot to get the Internet accounts applet to function. Was then able to successfully add both Google and Microsoft accounts with 2FA.

Comment 22 Mikhail 2016-10-25 19:11:13 UTC
Not fixed yet.

$ evolution --version
evolution 3.22.1
$ rpm -qa | grep evolution
evolution-help-3.22.1-2.fc25.noarch
evolution-data-server-3.22.1-1.fc25.x86_64
evolution-ews-3.22.1-1.fc25.x86_64
evolution-3.22.1-2.fc25.x86_64

For reproduction please login under Xorg session and then logoff and relogin under Wayland session. After it launch evolution you'll see this bug again.

Comment 23 Mikhail 2016-10-25 19:11:46 UTC
Created attachment 1214049 [details]
screenshot

Comment 24 Mikhail 2016-10-25 19:13:25 UTC
P.S. and google drive became unavailable in nautilus.

Comment 25 Debarshi Ray 2016-12-08 10:09:04 UTC
(In reply to Debarshi Ray from comment #4)
> This sounds like the bug about systemd user sessions not cleaning up daemons
> after logout. However, I don't have a bug number at hand, so I am unable to
> mark this is a duplicate.
> 
> (On Fedora 24, the D-Bus user session bus is setup by systemd --user.)

Another consequence of this is that if you log out/in, then goa-daemon cannot talk to gnome-keyring, which prevents all the accounts from working. The workaround is to reboot instead of log out/in.

Comment 26 Matěj Cepl 2016-12-08 15:32:04 UTC
*** Bug 1402670 has been marked as a duplicate of this bug. ***

Comment 27 Shaun Assam 2017-01-13 21:34:01 UTC
Another workaround that is working for me, and is less of a nuisance than rebooting, is to create a login application/script that executes the command 'goa-daemon --replace'.  I created a new file in ~/.config/autostart/ called goa-replace.desktop, and in a text-editor entered the following:

[Desktop Entry]
Name=GOA Replace
Exec=/usr/libexec/goa-daemon --replace
NoDisplay=true
Terminal=false
Type=Application


Since adding this file the credentials error no longer appears in Evolution, or when accessing my Google Drive from Nautilus.  I have tested this by performing login/logout ten times, rebooted the computer, and did login/logout another ten times.  I have not noticed any system quirks or other issues since applying this method.

Comment 28 Frank Crawford 2017-01-15 07:05:59 UTC
(In reply to Shaun Assam from comment #27)

Thanks for that workaround, it works for me and saves me having to go through a longer process when I log in.

Comment 29 Debarshi Ray 2017-01-31 09:53:16 UTC
*** Bug 1417806 has been marked as a duplicate of this bug. ***

Comment 30 Fedora Blocker Bugs Application 2017-02-08 15:14:44 UTC
Proposed as a Blocker for 26-final by Fedora user sgallagh using the blocker tracking app because:

 This may be a conditional violation of:
"Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops." from the Final criteria.

Comment 32 Geoffrey Marr 2017-02-13 20:27:21 UTC
Discussed during the 2017-02-13 blocker review meeting: [1]

The decision was made to delay the classification of this as a bug as we are unsure of how widespread this issue is. We would like clarification from the developers on how large of a problem this is before we vote.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-02-13/f26-blocker-review.2017-02-13-18.01.txt

Comment 33 Michael Catanzaro 2017-02-13 20:58:45 UTC
I would imagine the issue affects everyone....

It makes user switching worthless, since e.g. Evolution doesn't work at all after a log out and relogin until next reboot.

Comment 34 Jean-Pierre Rupp 2017-02-17 14:12:32 UTC
Not only the goa-daemon process stays running after logout, but a bunch of other processes as well. Shouldn't every process linked with a user's session be terminated when a user's session ends?

Comment 35 Geoffrey Marr 2017-02-27 19:04:35 UTC
Discussed during the 2017-02-27 blocker review meeting: [1]

The decision to classify this bug as an accepted blocker was made as it violates the following Final-blocker criteria:

"Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops" in the case of a logout or user switch.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2017-02-27/f26-blocker-review.2017-02-27-17.00.txt

Comment 36 Christian Stadelmann 2017-05-09 08:27:00 UTC
(In reply to Dawid Zamirski from comment #2)
> I can reproduce this by following the steps below:
> 
> 1. On freshly booted system, start Evolution -> ok
> 2. Close Evolution
> 3. Logout (not reboot)
> 4. Login
> 5. Start Evolution -> Failed to retrieve credentials from keyring
> 6. Reboot
> 7. Start Evolution -> Ok
> 
> So this happens to me every time I logout and log back in to the system.

(In reply to Michael Catanzaro from comment #33)
> I would imagine the issue affects everyone....
> 
> It makes user switching worthless, since e.g. Evolution doesn't work at all
> after a log out and relogin until next reboot.

It is not that easy, I can't always reproduce this bug, it only happens rarely when following the steps above. Also, I noticed that sometimes closing and restarting evolution is enough to work around this bug – which is contrary to the explanations above. I am not sure I might be running into a separate bug though.

Comment 37 Jan Kurik 2017-05-25 08:43:40 UTC
Removing this bug from the list of Prioritized bugs as it is already on list of blockers.

Comment 38 Adam Williamson 2017-06-14 18:36:35 UTC
Ping? We are now out of the Beta phase, and Final blockers need to be fixed. Is anyone working on this?

Comment 39 David Demelier 2017-06-15 12:58:58 UTC
I'm affected by this bug as well.

Comment 40 Paul W. Frields 2017-06-19 13:33:59 UTC
Based on Workstation WG meeting, assigning to halfline for the moment; cschaller will follow up.

Comment 41 Fedora Update System 2017-06-21 21:35:30 UTC
gnome-session-3.24.1-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-782a98300e

Comment 42 Fedora Update System 2017-06-23 06:24:54 UTC
gnome-session-3.24.1-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-782a98300e

Comment 43 Fedora Update System 2017-06-24 03:07:36 UTC
gnome-session-3.24.1-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 44 Brian J. Murrell 2017-06-24 17:49:46 UTC
Before we close and forget about this bug, can we have a fix for Fedora 25 since that's still what is current and stable and the version this bug was actually opened for?

Comment 45 Andre Robatino 2017-06-24 18:26:05 UTC
Removed the F26 Final Blocker status since it was pushed to F26 stable. Hope I did this correctly.

Comment 46 Adam Williamson 2017-06-27 01:10:41 UTC
May as well drop the whiteboard field too, to avoid confusion. Thanks, Andre!

Comment 47 Debarshi Ray 2017-07-14 10:13:07 UTC
Reassigning to gnome-session, since that is where the patches are.

Comment 48 Mark Silence 2017-07-17 17:53:44 UTC
I still experience the behavior described in Bug 1338761, which is marked as a duplicate of this bug, in Fedora 26 with  gnome-session-3.24.1-2.fc26 installed. I find this in the log files, but the Credentials have expired message remains:

Jul 17 12:52:18 invention.inside.madasi.com gnome-keyring-daemon[1686]: asked to register item /org/freedesktop/secrets/collection/login/1, but it's already registered

Comment 49 Nils Philippsen 2017-07-28 09:27:41 UTC
(In reply to Mark Silence from comment #48)
> I still experience the behavior described in Bug 1338761, ...

Same here.

Comment 50 Rob Riggs 2017-08-20 22:22:47 UTC
Please bump this to Fedora 26.  It still exists.

This has reached "most annoying defect of the decade" status for me.

Comment 51 Rob Riggs 2017-08-20 22:40:15 UTC
Also, https://bugzilla.redhat.com/show_bug.cgi?id=1417806 is marked as a duplicate of this defect, yet the steps to reproduce that defect is not the same as the one shown above for this one.  The only step needed to get "goa-daemon[xxx]: secret_password_lookup_sync() returned NULL" in the logs is to login.  It starts happening during initial login and continues forever.

Aug 19 12:29:16 emerald journal: secret_password_lookup_sync() returned NULL
Aug 19 12:29:16 emerald journal: /org/gnome/OnlineAccounts/Accounts/account_1377485001: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: No credentials found in the keyring (goa-error-quark, 4)
...
Aug 19 12:29:40 emerald journal: secret_password_lookup_sync() returned NULL

Either this bug is not the same and 1417806 was marked as a dupe of this one in error, or this defect still affects Fedora 26.

Comment 52 Christian Stadelmann 2017-08-21 09:44:55 UTC
(In reply to Christian Stadelmann from comment #36)
> (In reply to Dawid Zamirski from comment #2)
> > I can reproduce this by following the steps below:
> > 
> > 1. On freshly booted system, start Evolution -> ok
> > 2. Close Evolution
> > 3. Logout (not reboot)
> > 4. Login
> > 5. Start Evolution -> Failed to retrieve credentials from keyring
> > 6. Reboot
> > 7. Start Evolution -> Ok

I see this happen rarely on F26 too.

Comment 53 Jean-François Fortin Tam 2017-09-11 01:49:36 UTC
It happens to me all the time, sometimes once every few days, sometimes multiple times a day, and it's absolutely horrendous to have Evolution go AWOL on you and drop connections or refuse to (re)connect to anything. That's without even logging out, as I only suspend/resume and start/close Evolution. Fedora 26 feels horrendously unproductive for me just because of this. Seems to happen on one machine (super fast 6th-gen Intel laptop) much more than the other (2008 era) so I wouldn't be surprised if this was some race condition.

Comment 54 Fedora End Of Life 2017-11-16 19:00:55 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 55 Brian J. Murrell 2017-11-17 19:49:19 UTC
Can somebody please bump this up to F26 at least given comment #52 and the recentness of comment #53?

Comment 56 Rob Riggs 2018-02-04 17:33:27 UTC
It is possible that removing an old ~/.config/goa-1.0/accounts.conf file has resolved the problem for me.

Comment 57 Rob Riggs 2018-02-10 02:17:38 UTC
Since removing the old accounts.conf file, the goa-daemon has been running and functioning normal.

Comment 58 Fedora End Of Life 2018-02-20 15:22:59 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 59 Garrett Mitchener 2019-01-14 20:38:47 UTC
I just ran into this again on Fedora 29. My X11 session crashed, and when I logged in again, I can't sign in to google through Gnome.

Comment 60 Milan Crha 2019-01-15 09:22:55 UTC
(In reply to Garrett Mitchener from comment #59)
> I just ran into this again on Fedora 29. My X11 session crashed, and when I
> logged in again, I can't sign in to google through Gnome.

Does the whole machine restart help? If not, what is the exact error message, please?

Comment 61 Christian Stadelmann 2019-01-16 19:32:34 UTC
(In reply to Milan Crha from comment #60)
> (In reply to Garrett Mitchener from comment #59)
> > I just ran into this again on Fedora 29. My X11 session crashed, and when I
> > logged in again, I can't sign in to google through Gnome.
> 
> Does the whole machine restart help? If not, what is the exact error
> message, please?

I have not seen this issue in a very long time, but when I did, restarting the computer always helped. So did logging in to a tty and killing all the processes by that user.

Comment 62 Garrett Mitchener 2019-01-16 21:34:04 UTC
I managed to restart goa-daemon manually, and it's all working now. I suspect restarting the whole machine also fixes the problem.

The trouble is that there's no error message anywhere that I can find. I go to Settings, Online Accounts, and see that my Google credentials have expired. So I click on the Google account, go through all the screens to enter my password, and get back to the Settings window, and it still shows that my credentials have expired. And if I click again, enter my password, etc., same result, credentials still expired. But I never get an error message.

What must have happened is that when X crashed, somehow goa-daemon didn't get restarted properly.

In looking through journalctl --user, I see a few lines like this:

gnome-keyring-daemon[880393]: asked to register item /org/freedesktop/secrets/collection/login/414, but it's already registered

and I don't really see anything else that looks relevant.

Comment 63 Ben Cotton 2019-05-02 19:23:36 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 64 Ben Cotton 2019-05-02 19:43:29 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 65 wintonian 2019-05-04 06:56:56 UTC
Just experienced the behaviour in #1338761 running Fedora 30

A restart does solve the issue.

In this case wayland crashed sending me back to GDM and the credentials expired error was then apparent for all online accounts.


Note You need to log in before you can comment on or make changes to this bug.