Bug 1032620

Even happens if I just click Send/Receive twice.

Proposing as a blocker as per http://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Desktop_keyring

A similar issue seems to affect calendars: logging out and logging in again causes password prompts for every configured calendar.

Strangely, this is working now. I'm not entirely sure what changed. I was trying to debug the issue by watching DBus messages, and now the passwords seem to be remembered.

Weird... I will reopen if I figure out the cause.

Discussed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . This is provisionally accepted as a blocker: if it's reproducible as described we would consider it to be a blocker. roshi (Mike Ruckman) will attempt to reproduce the bug and mark it as an accepted blocker if he finds it is as described; if not, we will discuss it again at the next blocker review meeting.

Installed Final TC1 to a fresh VM, added a POP account to Evolution. Saved password to the keyring, and never had to enter it again. Leaving bug as is.

(In reply to Tim Waugh from comment #4)
> Strangely, this is working now. I'm not entirely sure what changed. I was
> trying to debug the issue by watching DBus messages, and now the passwords
> seem to be remembered.
> 
> Weird... I will reopen if I figure out the cause.

All the password management is done on the evolution-source-registry side, and it happens sometimes (quite rarely for me, even still annoying), that libsecret doesn't connect (I think) to its counterpart properly for some reason, which makes all passwords forgotten and user is forced to reenter them. Sadly the entered password is not saved either. I suppose something like this happened to you too. I do not know, but one theory was that the evolution-source-registry process is run before the libsecret, thus it doesn't get connected properly. In any case usual fix is a re-start of all running evolution processes, (if under gnome-shell, then evolution-calendar-factory as the last, because it's auto-restarted there).

OK, I'm seeing this right now. What diagnostics would you like?

Here's one datapoint: the requested e-source-uid values don't match any of the keys in my keyring, whereas when everything is working they do match.

$ dbus-monitor --session interface='org.freedesktop.Secret.Service'
signal sender=org.freedesktop.DBus -> dest=:1.97 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.97"
method call sender=:1.37 -> dest=:1.10 serial=356 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384954518.14917.17@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=357 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=GetSecrets
   array [
      object path "/org/freedesktop/secrets/collection/login/1576"
   ]
   object path "/org/freedesktop/secrets/session/s2"
method call sender=:1.37 -> dest=:1.10 serial=358 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384954518.14917.17@rubik"
      )
   ]
signal sender=:1.10 -> dest=(null destination) serial=496 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CollectionChanged
   object path "/org/freedesktop/secrets/collection/login"
method call sender=:1.37 -> dest=:1.10 serial=387 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163047.2561.19@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=388 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163047.2561.19@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=393 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=395 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=399 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163011.2561.14@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=400 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163011.2561.14@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=411 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162932.2561.4@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=412 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162932.2561.4@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=426 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162977.2561.9@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=428 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162977.2561.9@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=433 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163221.2561.44@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=434 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163221.2561.44@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=438 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163117.2561.29@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=439 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163117.2561.29@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=475 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=476 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]

There are no keys matching "14917" (in Passwords and Keys, Passwords->login, putting "14917" in the filter box).

For "2561" the only keys are:
Evolution Data Source 1384163084.2561.24@rubik
Evolution Data Source 1384163153.2561.34@rubik

Not sure if it's related: while reading through mail, the unread message count is not changing at all.

After restarting, unread message counts are updating, so I guess that was an unrelated bug.

Could this forgotten-passwords bug be related to goa-daemon crashing? I'm also seeing bug #1031662.

(In reply to Milan Crha from comment #7)
> I do not know, but one theory was that the
> evolution-source-registry process is run before the libsecret, thus it
> doesn't get connected properly.

So, I see evolution-source-registry as PID 1986... but gnome-keyring-daemon (is that what you meant by libsecret) is PID 1649.

> In any case usual fix is a re-start of all
> running evolution processes, (if under gnome-shell, then
> evolution-calendar-factory as the last, because it's auto-restarted there).

I'll try that shortly.

Further to comment #9, .config/evolution/sources has these sources:

1241181522.20211.26.source
1241542204.19984.1.source
1320148696.31410.5.source
1348585860.1585.2
1348585860.1585.3
1359477224.12743.15
1359477224.12743.18
1359477224.12743.26
1384162932.2561.4
1384162977.2561.9
1384163011.2561.14
1384163047.2561.19
1384163084.2561.24
1384163117.2561.29
1384163153.2561.34
1384163187.2561.39
1384163221.2561.44
1384954518.14917.12
1384954518.14917.17
1384954518.14917.26
local.source
vfolder.source

For comparison, gnome-keyring lists these keys as matching "evolution":

Evolution Data Source 1320148394.31410.2
Evolution Data Source 1320148455.31410.3
Evolution Data Source 1320148768.31410.6
Evolution Data Source 1320148897.31410.8
Evolution Data Source 1339575942.16936.1
Evolution Data Source 1347019761.6661.1
Evolution Data Source 1348589942.2761.0@localhost
Evolution Data Source 1348659056.20613.0@rubik
Evolution Data Source 1354181928.1745.6@rubik
Evolution Data Source 1354182186.1745.12@rubik
Evolution Data Source 1358341218.1835.0@rubik
Evolution Data Source 1384163084.2561.24@rubik
Evolution Data Source 1384163153.2561.34@rubik

I have 2 mail accounts configured requiring passwords, and 10 CalDav calendars requiring passwords.

Created attachment 827230 [details]
DBus messages to/from gnome-keyring-daemon while starting evolution

Here's the D-Bus conversation again, this time with replies.

Is evolution-data-source asking for the wrong source ID? Are the source IDs not stable in some way?

Hmm, too many questions/concerns. Let's deal with this randomly:

a) not updated unread counts, you probably see:
   https://bugzilla.gnome.org/show_bug.cgi?id=711443

b) persistent source ID: yes, they are supposed to be persistent, only with
   some exceptions, like GOA accounts, which are tight to GOA ID.
   Such generated sources live in ~/.cache/evolution/sources

c) when you mention GOA, do you have your POP account configured through it?

(In reply to Milan Crha from comment #14)

> b) persistent source ID: yes, they are supposed to be persistent, only with
>    some exceptions, like GOA accounts, which are tight to GOA ID.
>    Such generated sources live in ~/.cache/evolution/sources

I just have a 'trash' directory there.

> c) when you mention GOA, do you have your POP account configured through it?

No, I don't.

I closed evolution and killed the evolution processes in the order you said, evolution-calendar-factory last. 'ps axf | grep [e]vol' shows no processes. Shortly afterwards, both evolution-calendar-factory and evolution-source-registry were restarted automatically, and I was prompted for several passwords again.

So, once this has happened, simply killing evolution processes does not fix the problem.

However, from snooping on the D-Bus session I found that at least one password is now working correctly, this one:

method call sender=:1.342 -> dest=:1.10 serial=202 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163084.2561.24@rubik"
      )
   ]
method return sender=:1.10 -> dest=:1.342 reply_serial=202
   array [
      object path "/org/freedesktop/secrets/collection/login/1583"
   ]
   array [
   ]

Note that it had *not* asked for this e-source-uid previously.

For some reason, evolution is not asking for the correct e-source-uid secrets in some situations.

I've restarted the system and logged in, and I am still prompted for passwords.

Just to be clear: this was all working fine yesterday (comment #4). The required passwords are still there in gnome-keyring, but evolution is asking for the wrong e-source-uids.

Could you replace /usr/libexec/evolution-source-registry with a script, which will run the original evolution-source-registry, only with redirected output to a file, thus it'll be easier to see what happened in the background, please? Say something like:
   $ cd /usr/libexec
   $ mv evolution-source-registry evolution-source-registry.orig
   $ nano evolution-source-registry

       #!/bin/bash
       echo "-------------------" >> /tmp/esf-log.txt
       date >> /tmp/esf-log.txt
       echo "-------------------" >> /tmp/esf-log.txt
       /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt

   $ chmod a+x evolution-source-registry
   $ restart

which also distinguishes between different runs by adding a delimiter to the /tmp/esf-log.txt file. evolution-source-registry tends to write errors on the console, thus this may help, I hope.

Since last week I've had to provide all my passwords in order to get some things done, so we'll have to wait for this problem to happen again before having a chance to debug it.

In the mean time, I'll put a script there as you suggest.

Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . As no-one else seems to have run into this kind of problem in desktop validation testing, we're satisfied the keyring stuff is basically working, and Tim's just running into some sort of unusual case, so this does not need to block the release.

This bug is still lurking.

gnome-shell-3.10.3-8.fc20.x86_64
evolution-3.10.4-1.fc20.x86_64
evolution-data-server-3.10.4-1.fc20.x86_64
gnome-keyring-3.10.1-1.fc20.x86_64

I have four pop accounts with passwords. In the past a password for one or other account appeared to be forgotten on rare occasions. Entering it when prompted always cleared the problem.  Today evolution forgot the passwords for all of my accounts and he did not remember them when passwords were re-entered.  I logged out and logged back in and the problem continued.  After rebooting and powering down and then restarting I was able to re-enter the passwords and they were remembered. I suspect the power down did not really have anything to do with the problem going away.
  
I wrote a script as recommended in Comment 18 but I changed:

FROM /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt

TO   /usr/libexec/evolution-source-registry.orig >> /tmp/esf-log.txt &

Re-direction must be done before executing in the background.

If this happens again I will post the log.

(In reply to Norman Smith from comment #21)
> FROM /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt
> 
> TO   /usr/libexec/evolution-source-registry.orig >> /tmp/esf-log.txt &
> 
> Re-direction must be done before executing in the background.

No, the meaning of "&>>..." is different from ">>...&", the first means redirect all output streams into the file and wait for the end of application, while the second redirects only stdout to a file (completely omitting stderr) and run in the background, with immediate end of the script. Try 'man bash' and search for "Redirecting Standard Output and Standard Error" section, together with the following "Appending Standard Output and Standard Error" section.

Hello Milan:

You are correct. I am well aware of the function of &>> but there is a space between the & and the >> in comment 18. I should not of taken your comment literally. I should have realized it was just a typo error.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I am seeing this issue after upgrading evolution-data-server from 3.10.4-4.fc20 to 3.10.4-5.fc20. Evolution kept asking for passwords when receiving or sending emails every single time.
The problem went away after downgrading.

(In reply to Robert Buchholz from comment #25)
> I am seeing this issue after upgrading evolution-data-server from
> 3.10.4-4.fc20 to 3.10.4-5.fc20. Evolution kept asking for passwords when
> receiving or sending emails every single time.
> The problem went away after downgrading.

Thanks for the update. You are the second reporting this. There had been no change regarding POP passwords in that particular update, though. Password issues are usually caused by an issue with libsecret, which connect to gnome-keyring (or kwallet), which exposes org.freedesktop.secrets D-Bus service. This all is done on the evolution-source-registry side. By any chance, did you restart the system after the upgrade to 3.10.4-5? Does the same happen if you run:
   $ /usr/libexec/evolution-source-registry
from a console? Does it print any critical warnings there?

I ask, because there are also people reporting correct behaviour after the update.

This just happened again, but I'm afraid the script was not in place. :-(

I found that logging out and logging in again without entering the passwords it was asking for (calendars and POP3 mail) made it remember them again.

These journal entries look suspicious:

Jan 20 09:32:55 rubik org.gnome.evolution.dataserver.Sources3[2076]: ** Message: received an invalid or unencryptable secret

I got 37 of them on the failed login which asked for passwords, and none on "normal" login (like this one) where it remembers them.

I should mention versions:
evolution-3.12.9-1.fc21.x86_64
evolution-data-server-3.12.9-2.fc21.x86_64

That looks like an error returned by libsecret. I believe the logout & login restarted the background libsecret service and everything went working normal again.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 '21'.

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 21 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 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.