Bug 354041 - Evolution and gnome-keyring-daemon hang (livelock)
Evolution and gnome-keyring-daemon hang (livelock)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
11
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
: Reopened
: 418731 447332 498871 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-26 09:22 EDT by Mikkel Lauritsen
Modified: 2015-03-03 17:31 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:28:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mikkel Lauritsen 2007-10-26 09:22:40 EDT
Sometimes Evolution and gnome-keyring-daemon enter into a livelock situation
where the processes consume all available CPU and memory according to top. This
causes the entire machine to become unresponsive - mouse and keyboard stop
responding - and the only way out has been to power off.

Evolution is running against an Exchange server. The installed packages are
evolution-2.12.1-3
evolution-exchange-2.12.1-1
nome-keyring-2.20-6

/var/log/messages contains a number of entries like

Oct 26 14:14:59 kapowdk-mil gnome-keyring-daemon[2556]: couldn't read 4 bytes
from client: 
Oct 26 14:16:00 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
102373 times
Oct 26 14:17:01 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
101580 times
Oct 26 14:18:02 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
99584 times
Oct 26 14:19:03 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
100202 times
Oct 26 14:20:04 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
102133 times
Oct 26 14:21:05 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
101572 times
Oct 26 14:22:06 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
98907 times
Oct 26 14:23:07 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
100850 times
Oct 26 14:24:08 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
102861 times
Oct 26 14:25:09 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
102520 times
Oct 26 14:26:10 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
98876 times
Oct 26 14:27:11 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
97944 times
Oct 26 14:28:12 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
101612 times
Oct 26 14:29:13 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
102587 times
Oct 26 14:30:14 kapowdk-mil gnome-keyring-daemon[2556]:last message repeated
54889 times

So far the livelock has happened twice today, but unfortunately I don't know
what causes it to happen. Sometimes Evolution loses connection to the Exchange
server and gives a message saying that the Exchange backend process has
disappeared, but I haven't seen any direct relation between these events.
Comment 1 Matthew Barnes 2007-11-05 10:06:12 EST
Is this still reproducible with the latest Fedora 8 release candidate?
Comment 2 Mikkel Lauritsen 2007-11-06 02:53:24 EST
Yup. I have mainly been using the web interface to handle my mail, so I haven't
seen it a lot lately, but just starting Evolution has caused the following
entries in /var/log/messages over the past 5 minutes:

Nov  6 08:48:22 kapowdk-mil gnome-keyring-daemon[5620]: couldn't read 4 bytes
from client: 
Nov  6 08:50:11 kapowdk-mil gnome-keyring-daemon[5620]:last message repeated 2 times
Nov  6 08:51:12 kapowdk-mil gnome-keyring-daemon[5620]:last message repeated
91902 times
Nov  6 08:52:13 kapowdk-mil gnome-keyring-daemon[5620]:last message repeated
97308 times
Comment 3 Mikkel Lauritsen 2007-11-06 03:05:36 EST
To show the effects on the machine, these are the topmost two lines output by
top after the 5 minutes:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5620 mil       20   0  204m 1748 1412 S   79  0.1  10:39.36 gnome-keyring-d    
24040 mil       20   0  953m 399m  23m S   25 19.8   1:49.06 evolution          
   
Basically Evolution keeps ballooning until all of the available memory and swap
is used and the entire operating system goes south.

Platform is still x86_64, installed packages are

evolution-2.12.1-3.fc8
evolution-exchange-2.12.1-1.fc8
gnome-keyring-2.20.1-3.fc8
Comment 4 Matthew Barnes 2007-12-11 16:56:36 EST
Possibly a dupe of bug #322151.  Do you use a translated desktop?  Are you still
seeing the problem with the latest Fedora 8 updates?
Comment 5 Mikkel Lauritsen 2007-12-12 05:53:45 EST
Yup, I still see the problem. I've had Evolution running for 20 minutes now,
causing initially (only) 9 of the "couldn't read 4 bytes from client:" messages
in the logs, but after I have composed and sent a new message I got

Dec 12 11:31:51 kapowdk-mil gnome-keyring-daemon[2675]:last message repeated
96437 times
Dec 12 11:32:52 kapowdk-mil gnome-keyring-daemon[2675]:last message repeated
95946 times

with gnome-keyring-daemon and evolution in the usual livelock:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND       
 2675 mil       20   0  204m 1784 1444 S   76  0.1   1:49.15 gnome-keyring-d   
                                                                               
                                                         
19680 mil       20   0  833m 159m  22m S   26  7.9   0:42.90 evolution   

So, it appears that it's something in relation to writing messages that cause
the livelock to appear.

The desktop is en_US.UTF-8 and the packages installed are

evolution-2.12.2-2.fc8.x86_64
evolution-exchange-2.12.2-1.fc8.x86_64
gnome-keyring-2.20.2-1.fc8.x86_64
Comment 6 Mikkel Lauritsen 2008-02-18 08:34:30 EST
Also reported at
http://www.mail-archive.com/evolution-hackers@gnome.org/msg02087.html
Comment 7 Mikkel Lauritsen 2008-02-18 09:04:59 EST
As described in the thread that I added a link to in the previous comment,
deleting and re-creating the default keyring using gnome-keyring-manager has
apparently made the problem disappear. I can now compose a mail from Evolution
without it going into a collective tailspin with gnome-keyring-daemon.

It made the problem from bug 296671 re-appear, but setting Authentication Type
to Secure Password and providing a host name for the Global Catalog server has
fixed that as well.
Comment 8 Christian Schaller 2008-04-02 12:01:23 EDT
I am running latest Fedora with updates and are getting this same problem with
var/log/messages saying:
Apr  2 14:54:32 localhost gnome-keyring-daemon[2629]: couldn't read 4 bytes from
client: 

Evolution currently never works with gnome-keyring-daemon, while NetworkManager
seems to work every second boot.
Comment 9 Matthew Barnes 2008-04-02 12:11:31 EDT
Reassigning to gnome-keyring.

I believe this is a keyring configuration issue.  I vaguely recall it had
something to do with gnome-screensaver writing a bogus keyring file to
~/.gnome2/keyrings, but can't remember the details.  Ray, do you remember?

I believe the issue has since been fixed in gnome-keyring, but the damage done
to users' keyring configurations has to be manually repaired.

Trying to find a more informative bug # to reference...
Comment 10 Christian Schaller 2008-04-02 14:38:45 EDT
Thought I should mention that I ended up using the gnome-keyring-manager to
resolve this today. Removing 'default' keyring did not help me, but removing a
keyring called 'login' did. Noticed that when it now repopulates my default
keyring a 'login' keyring seems not to be created.

Also you might want to mark bug 426463 a duplicate of this one.
Comment 11 Jonathan Kamens 2008-04-02 22:06:10 EDT
I have this problem, and blowing away ~/.gnome2/keyrings does not solve it.
Comment 12 Matthew Barnes 2008-05-19 11:24:38 EDT
*** Bug 447332 has been marked as a duplicate of this bug. ***
Comment 13 zephod 2008-06-04 11:03:45 EDT
I have a similar problem but this is on an updated F9 x86_64 system and the main
difference is that only Evolution locks up, not the whole computer. System
monitor shows that the Evolution processes, evolution, evolution-alarm-notify,
evolution-data-server-2.22 and evolution-exchange-storage are all sleeping and
consuming 0% CPU. The problem only happens when I compose an new message or
reply to a message and it usually takes ~10 secs after opening a new window
before the window becomes unresponsive.

# rpm -qa | grep evolution
evolution-data-server-2.22.1-2.fc9.x86_64
evolution-data-server-2.22.1-2.fc9.i386
evolution-data-server-debuginfo-2.22.1-2.fc9.x86_64
evolution-data-server-devel-2.22.1-2.fc9.i386
evolution-data-server-doc-2.22.1-2.fc9.x86_64
evolution-2.22.1-2.fc9.i386
evolution-webcal-2.21.92-1.fc9.x86_64
evolution-data-server-devel-2.22.1-2.fc9.x86_64
evolution-webcal-debuginfo-2.21.92-1.fc9.x86_64
evolution-2.22.1-2.fc9.x86_64
evolution-spamassassin-2.22.1-2.fc9.x86_64
evolution-debuginfo-2.22.1-2.fc9.x86_64
evolution-conduits-2.22.1-2.fc9.x86_64
evolution-exchange-2.22.1-1.fc9.x86_64
evolution-bogofilter-2.22.1-2.fc9.x86_64

# rpm -qa | grep keyring
gnome-python2-gnomekeyring-2.22.0-2.fc9.x86_64
gnome-keyring-2.22.1-1.fc9.x86_64
gnome-keyring-devel-2.22.1-1.fc9.x86_64
gnome-keyring-pam-2.22.1-1.fc9.x86_64
gnome-keyring-2.22.1-1.fc9.i386

Comment 14 Jonathan Underwood 2008-06-08 09:46:44 EDT
I see exactly the same problem as described in comment #13 on a fully updated
F-9 install:

$ rpm -qa | grep evolution
evolution-data-server-2.22.2-1.fc9.x86_64
evolution-webcal-2.21.92-1.fc9.x86_64
evolution-exchange-2.22.2-1.fc9.x86_64
evolution-2.22.2-2.fc9.x86_64

$ rpm -qa | grep keyring
gnome-keyring-manager-2.20.0-2.fc9.x86_64
gnome-keyring-pam-2.22.1-1.fc9.x86_64
gnome-python2-gnomekeyring-2.22.0-2.fc9.x86_64
gnome-keyring-2.22.1-1.fc9.x86_64

In particular, Evolution will start fine and work up until I start to compose a
message. After a second or two, evolution just locks up, but doesn't consume and
CPU. I see this in /var/log/messages:

Jun  8 14:38:13 localhost gnome-keyring-daemon[2734]: couldn't read 4 bytes from
client:

repeated many times.

Running with strace shows this as the last output (only pasting a few screens worth:

munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0f\0\0\0\v\0\0\0\1\0\0\0"..., 119) = 119
read(56, "\0\0\0\231", 4)               = 4
read(56, "\0\0\0\0\0\0\0\5login\0\0\0\5\0\0\0\nzvX17ii9bQ\0"..., 149) = 149
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
writev(23, [{"GIOP\1\2\1\0\227\0\0\0", 12},
{"\250l\341T\0\0\0\0\0\0\0\0\34\0\0\0\5\0\0\0P\226<h\347\3140p\4\361\360\360"..., 151}],
2) = 163
futex(0xa0d7b0, FUTEX_WAKE_PRIVATE, 1)  = 1
read(3, 0x9fa484, 4096)                 = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=34, events=POLLIN},
{fd=49, events=POLLIN}], 6, 0) = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
close(56)                               = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0}\0\0\0\v\0\0\0\1\0\0\0"..., 142) = 142
read(56, "\0\0\0\10", 4)                = 4
read(56, "\0\0\0\t", 4)                 = 4
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0f\0\0\0\v\0\0\0\1\0\0\0"..., 119) = 119
read(56, "\0\0\0\231", 4)               = 4
read(56, "\0\0\0\0\0\0\0\5login\0\0\0\5\0\0\0\nzvX17ii9bQ\0"..., 149) = 149
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
writev(23, [{"GIOP\1\2\1\0\227\0\0\0", 12},
{"\250l\341T\0\0\0\0\0\0\0\0\34\0\0\0\5\0\0\0P\226<h\347\3140p\4\361\360\360"..., 151}],
2) = 163
futex(0xa0d7b0, FUTEX_WAKE_PRIVATE, 1)  = 1
read(3, 0x9fa484, 4096)                 = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=34, events=POLLIN},
{fd=49, events=POLLIN}], 6, 0) = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
close(56)                               = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0}\0\0\0\v\0\0\0\1\0\0\0"..., 142) = 142
read(56, "\0\0\0\10", 4)                = 4
read(56, "\0\0\0\t", 4)                 = 4
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0f\0\0\0\v\0\0\0\1\0\0\0"..., 119) = 119
read(56, "\0\0\0\231", 4)               = 4
read(56, "\0\0\0\0\0\0\0\5login\0\0\0\5\0\0\0\nzvX17ii9bQ\0"..., 149) = 149
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
writev(23, [{"GIOP\1\2\1\0\227\0\0\0", 12},
{"\250l\341T\0\0\0\0\0\0\0\0\34\0\0\0\5\0\0\0P\226<h\347\3140p\4\361\360\360"..., 151}],
2) = 163
read(3, 0x9fa484, 4096)                 = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN, revents=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=34, events=POLLIN},
{fd=49, events=POLLIN}], 6, 322) = 1
read(4, "A", 1)                         = 1
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
close(56)                               = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0}\0\0\0\v\0\0\0\1\0\0\0"..., 142) = 142
read(56, "\0\0\0\10", 4)                = 4
read(56, "\0\0\0\t", 4)                 = 4
close(56)                               = 0
munlock(0x7f5c40849000, 16384)          = 0
munmap(0x7f5c40849000, 16384)           = 0
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f5c40849000
mlock(0x7f5c40849000, 16384)            = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 56
fcntl(56, F_SETFD, FD_CLOEXEC)          = 0
connect(56, {sa_family=AF_FILE, path="/tmp/keyring-vfnFVe/socket"}, 110) = 0
write(56, "\0", 1)                      = 1
write(56, "\0\0\0\21\0\0\0\tevolution\0\0\0f\0\0\0\v\0\0\0\1\0\0\0"..., 119) = 119
read(56, 

That incomplete line really is the last line - it is just hung at that point.


Comment 15 Dimitris Kalamaras 2008-07-11 05:46:27 EDT
Exactly the same problem. Evolution, connected with Exchange, locks up my Fedora
9/x86 machine after a while. The file /var/log/messages is full of records like
this: 

Jul 11 12:22:34 workdesk gnome-keyring-daemon[2361]: couldn't read 4 bytes from
client: 

This message appears only when I run Evolution. And they are way too many. Look
at this:
-rw------- 1 root    root    872M 2008-06-09 11:18 messages-20080609
-rw------- 1 root    root    232M 2008-07-08 11:56 messages-20080708
-rw------- 1 root    root     71M 2008-06-23 15:12 messages-20080623


All these logs are full of the same message. 

Installed packages: 

$ rpm -qa | grep evolution
evolution-exchange-2.22.3-1.fc9.i386
evolution-data-server-2.22.3-1.fc9.i386
evolution-help-2.22.3.1-1.fc9.i386
evolution-webcal-2.21.92-1.fc9.i386
evolution-2.22.3.1-1.fc9.i386

$ rpm -qa | grep keyring 
gnome-keyring-2.22.3-1.fc9.i386
gnome-keyring-pam-2.22.3-1.fc9.i386


Comment 16 Dimitris Kalamaras 2008-07-11 05:51:14 EDT
Obviously, this is not a x86-64 specific bug. I am experiencing the same on i386
(Pentium 4).
Comment 17 Dimitris Kalamaras 2008-07-11 07:55:41 EDT
Problem was solved using gnome-keyring-manager (installed via yum). Following
comment #10, I deleted the 'login' keyring and now Evolution works nicely and
there are no redundant messages any more in /var/log/messages. Also, a new
'default' keyring has been created. 
Comment 18 Gilboa Davara 2008-10-14 05:24:39 EDT
Seeing the same (fully updated F9.)
Trying the solution suggested in comment #10.

... We'll see how it goes.

$ rpm -qa | egrep -e 'evolution|gnome-keyring' | sort
evolution-2.22.3.1-1.fc9.x86_64
evolution-conduits-2.22.3.1-1.fc9.x86_64
evolution-data-server-2.22.3-2.fc9.x86_64
evolution-data-server-devel-2.22.3-2.fc9.x86_64
evolution-data-server-doc-2.22.3-2.fc9.x86_64
evolution-help-2.22.3.1-1.fc9.x86_64
evolution-webcal-2.21.92-1.fc9.x86_64
gnome-keyring-2.22.3-1.fc9.x86_64
gnome-keyring-devel-2.22.3-1.fc9.x86_64
gnome-keyring-manager-2.20.0-2.fc9.x86_64
gnome-keyring-pam-2.22.3-1.fc9.x86_64
Comment 19 Gilboa Davara 2008-10-19 23:36:54 EDT
No go. Evolution still hands. (At a somewhat slower rate).

- Gilboa
Comment 20 Gilboa Davara 2008-10-19 23:37:40 EDT
s/hands/hangs/g
Comment 21 Bug Zapper 2008-11-26 03:06:44 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 WONTFIX if it remains open with a Fedora 
'version' of '8'.

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 prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Jonathan Underwood 2008-11-26 06:19:09 EST
I haven't hit this in F-9.
Comment 23 Gilboa Davara 2008-12-03 00:27:10 EST
Seeing the same issue in F10 and F9.
Only under KDE 4.x.

Bug 459356 might be a duplicate of this bug.

On a side note, can I somehow disable gnome-keyring-manager in evolution?

- Gilboa
Comment 24 Bug Zapper 2009-01-09 02:20:53 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 25 Christoph Wickert 2009-07-14 13:39:45 EDT
*** Bug 418731 has been marked as a duplicate of this bug. ***
Comment 26 Bug Zapper 2009-11-18 02:45:05 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 WONTFIX if it remains open with a Fedora 
'version' of '10'.

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 prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 27 Jonathan Underwood 2009-11-18 08:44:38 EST
I haven't seen this issue in a while now. Didn't see it throughout F-11, and now on F-12 I haven't experienced it yet.
Comment 28 Gilboa Davara 2009-11-25 22:37:31 EST
Still seeing it daily on F11.

- Gilboa
Comment 29 Christopher Beland 2010-02-23 03:22:06 EST
*** Bug 498871 has been marked as a duplicate of this bug. ***
Comment 30 Bug Zapper 2010-04-27 07:48:34 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 WONTFIX if it remains open with a Fedora 
'version' of '11'.

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 prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Bug Zapper 2010-06-28 06:28:08 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

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

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