Bug 1340203

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.

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.

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.

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.)

Aha, it can be it. I just noticed that neither the evolution-data-server background processes are stopped on logout.

(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
====

(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.

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?

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.

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

(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.

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.

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?

(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.

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.

...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.

*** Bug 1338761 has been marked as a duplicate of this bug. ***

*** Bug 1223117 has been marked as a duplicate of this bug. ***

Still not fixed in Fedora 25

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.

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.

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.

Created attachment 1214049 [details]
screenshot

P.S. and google drive became unavailable in nautilus.

(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.

*** Bug 1402670 has been marked as a duplicate of this bug. ***

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.

(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.

*** Bug 1417806 has been marked as a duplicate of this bug. ***

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.

The has been approved as a Prioritized bug: https://meetbot.fedoraproject.org/fedora-meeting/2017-02-08/fedora_prioritized_bugs_and_issues.2017-02-08-15.01.log.html

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

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.

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?

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

(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.

Removing this bug from the list of Prioritized bugs as it is already on list of blockers.

Ping? We are now out of the Beta phase, and Final blockers need to be fixed. Is anyone working on this?

I'm affected by this bug as well.

Based on Workstation WG meeting, assigning to halfline for the moment; cschaller will follow up.

gnome-session-3.24.1-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-782a98300e

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

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.

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?

Removed the F26 Final Blocker status since it was pushed to F26 stable. Hope I did this correctly.

May as well drop the whiteboard field too, to avoid confusion. Thanks, Andre!

Reassigning to gnome-session, since that is where the patches are.

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

(In reply to Mark Silence from comment #48)
> I still experience the behavior described in Bug 1338761, ...

Same here.

Please bump this to Fedora 26.  It still exists.

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

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.

(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.

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.

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.

Can somebody please bump this up to F26 at least given comment #52 and the recentness of comment #53?

It is possible that removing an old ~/.config/goa-1.0/accounts.conf file has resolved the problem for me.

Since removing the old accounts.conf file, the goa-daemon has been running and functioning normal.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

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.

(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?

(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.

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.

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.

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.

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.

I got here by way of bug 1417806 which was closed as a duplicate of this.  I am getting:

Oct 30 06:09:11 pc.example.com goa-daemon[14638]: secret_password_lookup_sync() returned NULL

messages in my journal.

It's kind of surprising that this issue has been ongoing for over 3 years and still relevant and current.

Even restarting goa-daemon doesn't seem to resolve it's constant complaining:

Oct 30 06:09:11 pc.example.com goa-daemon[14638]: secret_password_lookup_sync() returned NULL

> goa-daemon[14638]: secret_password_lookup_sync() returned NULL

Yeah, my logs are full of that shit too. I opened #1753129 a while back.

I use Mate and was constantly running into this issue. The solution for me has been to run:

/usr/libexec/goa-daemon --replace

If I do that, the problem is fixed.

I have added this command to the startup applications in Mate, via the Mate UI for this.

This is not a "fix" (as in we can close this ticket), this is a hacky work-around at best.

The root issue still need to be fixed so that these kinds of hacks are not necessary.

That said, the Version: is 30.  I wonder if anyone is hitting this in Fedora 31.  If so, please come here and update the Version: to 31.

I think we are mixing up various unrelated problems into this one bug report.

This bug isn't really about goa-daemon per se. The GNOME Online Accounts D-Bus service offered by goa-daemon is only the thing that shows the worst symptoms. This bug is about D-Bus services running on the user or session bus not getting stopped once the user has logged out. Terminating the D-Bus services is the responsibility of the components in charge of defining the lifetime of the GNOME session. eg., gnome-session.

To verify that, log out of your GNOME session, then log in through the Linux console (ctrl+alt+f3 and such) and check if you have any left over processes (eg., ps aux | grep goa).

The errors from secret_password_lookup_sync() are a different issue, and not relevant to gnome-session. Let's use a different bug for it.

It's not clear to me why this bug got reopened between comment 44 and comment 45.

I am not the gnome-session maintainer, neither upstream nor downstream, so I cannot comment whether the fixes should have been backported to Fedora 25 or not. Either way, the issue no longer relevant because all currently supported Fedoras are fixed.

Closing.

Can somebody with permission please reopen this and set the Version: to 32.  This still happens.

$ journalctl -S -24h | grep 'secret_password_lookup_sync() returned NULL' | wc -l
17401
$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 32 (Thirty Two)
Release:	32
Codename:	ThirtyTwo

(In reply to Brian J. Murrell from comment #73)
> Can somebody with permission please reopen this and set the Version: to 32. 
> This still happens.
> 
> $ journalctl -S -24h | grep 'secret_password_lookup_sync() returned NULL' |
> wc -l
> 17401

It's not necessarily this bug, is it? Can you confirm that the goa-daemon process ID (the first column of `ps ax | grep goa-daemon`) did not change after you log out and then log in again? I know you mentioned this error in the log earlier, but, from my point of view, this bug is not about that error, it's about properly stopping services on user's logout.

There is even some (systemd?) option, which can influence this (close session or logout) and which probably wasn't set in the previous version(s) of Fedora. I noticed somewhere some note about it, I only do not recall where it was and what exactly it was. I'm sorry.

Since Rishi resolved bug #1417806 as a duplicate of this issue, and the issue is still occurring, one bug or the other needs to be reopened.

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-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 '32'.

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 32 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.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have observed this bug today on Linux mint 21.3 (current).

gnome-online-accounts: 3.44.0+mint1+vanessa

I do not know how long my computer was online, but many days for sure.
It manifested itself in not being able to access my nextcloud files any more.
The day before I had to update my groups assignment, so I did actually log out on that day.
A reboot resolved the issue for me.

I will bookmark this ticket for me, and when it happens again, I will follow the tips on what to check from this bug report to see if I gain a better understanding of the issue and if I can fix it.

> gnome-online-accounts: 3.44.0+mint1+vanessa

The 3.44.0 is very old. It had been released more than two years ago, on 2022-03-30. This bug is closed for almost three years, even without any real fix. Still, using the latest versions is better for any investigation. I'm afraid there is no manpower to investigate such old software, neither here, nor in upstream. You can ask your distro maintainers though, whom maintain the package for you.