Bug 1938533

The error message seems entirely valid, so I do not think that there is anything to fix in gnome-keyring-daemon here (secret_monitor_scan_secrets_thread is not present in gnome-keyring). If you can demonstrate that the bug is related to the potentially-related bugs in the description, please comment in those bugs.

The evolution-data-server is the place where the code sits, not evolution, thus I'm moving this once again.

The errors says:

> evolution-sourc[403587]: secret_monitor_scan_secrets_thread: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached

The secrets monitor talks to the org.freedesktop.secrets D-Bus service to check what secrets are stored there and it eventually deletes those for which there is not a corresponding account configured.

If I read it correctly, this specific message means the D-Bus failed to start org.freedesktop.secrets service.
According to /usr/share/dbus-1/services/org.freedesktop.secrets.service, it's supposed to run:

   /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

This command:

   gdbus call --session -d org.freedesktop.secrets -o /org/freedesktop/secrets -m org.freedesktop.DBus.Properties.GetAll "org.freedesktop.Secret.Service"

is supposed to talk to the org.freedesktop.secrets. Can the customer execute it on one of the affected machines? Will it also timeout, or it'll return something like:

({'Collections': <[objectpath '/org/freedesktop/secrets/collection/session', '/org/freedesktop/secrets/collection/login']>},)

please?

Thanks for the update. I see the `secret_monitor_scan_secrets_thread` is called once per day, as expected. The machine/GNOME Shell is not restarted for several days, which means there will be a single `evolution-source-registry` process for the whole time. From the test gdbus call results I believe the gnome-keyring-daemon is started automatically, only the libsecret does not reconnect to the daemon one it's closed. That can be verified by:

   $ ps ax | egrep "evolution|gnome-keyring"

after the machine is restarted and then running the command again, after the runtime warning is logged into the journal. I suppose the gnome-keyring-daemon process will be either missing or it'll have a different process ID. Running the gdbus command will start a new gnome-keyring-daemon process.

Being it so, it's a libsecret bug:
https://gitlab.gnome.org/GNOME/libsecret/-/issues/39

I recall a rare cases when the gnome-keyring-daemon had been restarted shortly after the evolution-source-registry processes started after login, which reproduces the bug too, though then no password can be received from the keyring. I mention it, because in that case the gnome-keyring-daemon process ID from the above `ps` command won't change, but the things could be still broken.

As there is not much interest in the fix in the libsecret upstream, and considering the secret monitor on the evolution-source-registry side is not that critical, I can hide the error to not be shown in the logs. It won't help with any other errors being caused by the gnome-keyring-daemon restart, thus the change would be only about the logged error, not fixing the cause of the problem.

As a side note, restarting the evolution-data-server background processes should connect them to the current gnome-keyring-daemon (or start a new one), and fix the problem until the gnome-keyring-daemon is closed again. That can be done with: `evolution --force-shutdown`, if the 'evolution' package is installed, or by killing the processes with -TERM manually, in order:

   evolution-alarm-notify
   evolution-addressbook-factory
   evolution-source-registry
   evolution-calendar-factory

Could the customer verify what, or whether at all, a gnome-keyring-daemon process is running after login and when the error shows up, please? That's the next day. It's as simple as runnnig from a terminal:

   $ ps ax | egrep "gnome-keyri|evolution|gnome-shell"

which will show also the evolution-related and gnome-shell processes.

----------------------------------------------------------------------------

I gave this a try, using libsecret-0.18.6-1.el8.x86_64, and that can start a new gnome-keyring-daemon when I kill it from a terminal while the secret monitor from the evolution-data-server is running, as long as the main context of the first libsecret call is the main thread's main context. When I use a different thread default context for the first call (it's when the GDBusProxy is created), then things break, even in a different way than the above error message; I get:

   (evolution-source-registry:20135): module-secret-monitor-WARNING **: 17:48:54.644: secret_monitor_scan_secrets_thread:
   GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name :1.111 was not provided by any .service files

That reminded me of the 
   https://gitlab.gnome.org/GNOME/libsecret/-/issues/39
or better
   https://gitlab.gnome.org/GNOME/libsecret/-/issues/9 .

Okay, thus this is related to the vncserver. That's an important detail, from my point of view (I forgot of it since comment #9). What I consider interesting is that there are running two evolution-source-registry processes, one for each vncserver, but only one gnome-keyring-daemon. The claim in the journal comes from the second evolution-source-registry, which is ran in the second vncserver.

I do not know how the vncserver works.

It seems it behaves like a new user, with his/her own session being run on the machine. Otherwise there would be only a single evolution-source-registry (and all the other evolution processes). The question is why the second vncserver did not run also its own gnome-keyring-daemon. The only reason I can think of (I repeat, I do not know how the vncserver works), is that the gnome-keyring-daemon runs on a system bus (D-Bus), but that's unlikely. Also because the second evolution-source-registry would connect to it otherwise.

That being said, if the vncserver runs its own session (not system) D-Bus bus, then it should start also its own gnome-keyring-daemon. I'd expect the gnome-keyring-daemon works the same as the evolution-source-registry, but it seems they are setup differently. Looking into the /usr/lib/systemd/, the evolution-data-server processes are mentioned under the 'user' subdirectory, while the gnome-keyring-daemon is not mentioned at all there. The gnome-keyring-daemon is mentioned only under /usr/share/dbus-1/services. None of the two occurrences there have the command line shown above, at least on my machine, which, I guess, means the gnome-keyring-daemon was started by other ways.

From my point of view, once each vncserver will run also its own gnome-keyring-daemon, not only the evolution-data-server processes, the things will start working properly. Why it's not doing so I do not know.

I cannot make the vncserver from tigervnc-server-1.11.0-9.el8.x86_64 running here. Well, it runs, but I cannot connect to it. I cannot test it, but maybe if the gnome-keyring-daemon has its own systemd unit it'll work. Something similar to /usr/lib/systemd/user/evolution-source-registry.service, only referencing the gnome-keyring-daemon (or better the org.freedesktop.secrets) service.

The vncserver claims this when I run it here:

   WARNING: vncserver has been replaced by a systemd unit and is about to be removed in future releases.
   Please read /usr/share/doc/tigervnc/HOWTO.md for more information.

Again, I do not know how the vncserver works or what options it expects to have this working properly. You might have better luck asking someone whom knows that.

Adding Jan the TigerVNC maintainer. Jan, can you please take a look at comment 27 from Milan?

Debugging this I found a reproducer:
a) log out of GNOME
b) switch to a text terminal (Ctrl+Alt+F2) and log in as a user
c) check what related processes are running:
   $ ps ax | egrep "evolution|gnome-key"
   - none should be there
d) start the vncserver as: vncserver -fg &
e) wait until there's printed a line about "New desktop" for the user
f) check what related processes are running:
   $ ps ax | egrep "evolution|gnome-key"
   - this will show several evolution processes and the gnome-keyring-daemon, as expected
g) start another vncserver for the same user: vncserver -fg &
h) wait until there's printed a line about "New desktop" for the user
i) check what related processes are running:
   $ ps ax | egrep "evolution|gnome-key"
   - this will show the same evolution processes and the gnome-keyring-daemon as before,
     plus some new evolution process, but none new gnome-keyring-daemon
   - running the next vncserver for a different user will start also the gnome-keyring-daemon

Looking into the sources of the gnome-keyring package, it does not check whether the daemon is running on the D-Bus (which is unset by ~/.vnc/xstartup, thus the D-Bus processes are run in their own D-Bus session), it checks for existence of files. In this case, in the $XDG_RUNTIME_DIR/keyring/ directory. These are common for all the D-Bus sessions run for the user, thus the second gnome-keyring daemon stops as "the daemon is already running" and does not realize the daemon is running in a different D-Bus session. The gnome-keyring-daemon has an option --replace, but that would break the previous session, thus it won't help to anything.

I do not know the gnome-keyring-daemon, but I believe it has a reason why it wants to have only a single process running in the background, thus having two processes accessing the same keyring at the same time might cause some trouble.

I noticed when I connect to the vncserver session (step d) above), I'm asked for the keyring password, which is probably expected.

Anyway, I do not see any good option for this. Any workaround may either work only temporarily or will break other things (like when replacing the daemon or changing the XDG_RUNTIME_DIR for each vncserver instance).

-------------------------------------------------------------------------

I agree with Michael, the errors should be shown somewhere, but I also believe the errors from here are not as that important, because they only mean that some credentials could not be removed from the keyring for some reason. There is no data loss here. I made a change upstream [1] for it and I'll backport it to the evolution-data-server.

An interesting follow-up change would be to modify the gnome-keyring to work properly also in the multi-D-Bus-session environment.

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/210d2dc5d8d1dcf10f5444d5d8459db74de7ec73

Hmmmmm. So the problem is gnome-keyring breaks if there is more than one session bus per user. That used to be common -- each desktop session would have its own separate session bus -- but nowadays all desktop sessions normally share the same session bus (the "user bus"). I bet *lots* of other software expects there to be only one session bus per user, since that is how Fedora has worked for several years now. Not sure what to do about this....

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (evolution-data-server bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1782