Unable to read mail after resume due to akonadi hang

Bug #862483 reported by Scott Kitterman on 2011-09-29
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Akonadi
Incomplete
Medium
Release Notes for Ubuntu
Undecided
Unassigned
akonadi (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned

Bug Description

I few times since upgrading this laptop to KDE 4.7 (and moving from Kmail to
Kmail2) I've been unable to read email via imap. When I click on a message it
says "Retrieving folder contents, please wait" indefinitely.

I tried exiting kmail and restarting it, but still had the same problem. After
stopping and starting akonadi using the Akonadi Server Configuration KCM, then
it was able to read mail (without restarting kmail2 again).

Note: Akonadi version is actually 1.6.1, but I didn't see that option under
application version.

Reproducible: Sometimes

Steps to Reproduce:
Suspend laptop, resume laptop, check mail provided via an imap resource.

Actual Results:
"Retrieving folder contents, please wait"

Expected Results:
Mail retrieved so I can read it.

RELEASE NOTE:
Kmail/Kontact cannot reliably retrieve email after a suspend resume cycle. Sometimes after resume, instead of displaying messages, "Retrieving folder contents, please wait" will be persistently displayed. If this occurs, use the Akonadi Server Configuration control module to restart Akonadi. That should resolve this issue. Restarting Kontact/Kmail will not. To access the control module use the search function in Kickoff (K menu) or Quicksand (alt-F2) to find it.

Version: 1.6.0 (using KDE 4.7.1)
OS: Linux

I few times since upgrading this laptop to KDE 4.7 (and moving from Kmail to Kmail2) I've been unable to read email via imap. When I click on a message it says "Retrieving folder contents, please wait" indefinitely.

I tried exiting kmail and restarting it, but still had the same problem. After stopping and starting akonadi using the Akonadi Server Configuration KCM, then it was able to read mail (without restarting kmail2 again).

Note: Akonadi version is actually 1.6.1, but I didn't see that option under application version.

Reproducible: Sometimes

Steps to Reproduce:
Suspend laptop, resume laptop, check mail provided via an imap resource.

Actual Results:
"Retrieving folder contents, please wait"

Expected Results:
Mail retrieved so I can read it.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in akonadi (Ubuntu):
status: New → Confirmed
Changed in akonadi:
importance: Unknown → Medium
status: Unknown → New
Jürgen (j-w-ott) wrote :

akonadi seems to kill kmail in other situations too. I have one installation 4.7.1 where kmail hangs while writing emails or sending them or 'touching' the adress field.

If the user(1) logs out and uses ssh -Y user1@localhost kmail from another user2 session it seems that these hangups don't occur !!

I get a similar problem, but generally on all kinds of Akonadi resources immediately after KMail starts.

KMail version 4.7.1.

Akonadi uses an external, but local MYSQL server.

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

> Akonadi uses an external, but local MYSQL server.

Did you configure it ? specially the wait_timeout parameter ?

Download full text (5.5 KiB)

No, I left the default settings in /etc/my.conf, connecting to localhost as "root" (regardless whether using TCP/IP and UNIX socket):

# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /var/run/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port = 3306
socket = /var/run/mysql/mysql.sock
# Change following line if you want to store your database elsewhere
datadir = /var/lib/mysql
skip-external-locking
key_buffer_size = 16M
max_allowed_packet = 1M
table_open_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking

# Replication Master Server (default)
# binary logging is required for replication
log-bin=mysql-bin

# binary logging format - mixed recommended
binlog_format=mixed

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
# the syntax is:
#
# CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
# MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
# where you replace <host>, <user>, <password> by quoted strings and
# <port> by the master's port number (3306 by default).
#
# Example:
#
# CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
# MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
# start replication for the first time (even unsuccessfully, for example
# if you mistyped the password in master-password and the slave fails to
# connect), the slave will create a master.info file, and any later
# change in this file to the variables' values below will be ignored and
# overridden by the content of the master.info file, unless you shutdown
# the slave server, delete master.info and restart the slaver server.
# For that reason, you may want to leave the lines below untouched
# (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id = 2
#
# The replication master for this slave - required
#master-host = <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user = <username>
#
# The password the slave will authenticate with when connecting to
# the master - r...

Read more...

Interesting: After restart I always get 6 - 7 messages shown, but after clicking through them it hangs again with "Retrieving folder contents, please wait" and doesn't return.

Using MYSQL Server 5.5.16 from the openSUSE server:database repository, QtSQL client linked with MYSQL client r16 instead of r18. Maybe a bad combination, because OpenSUSE 11.4 still ships with 5.1.53?

correct,

ldd /usr/lib64/qt4/plugins/sqldrivers/libqsqlmysql.so |grep mysql

must return something valid.

and when using an external server, it has to be configured first (which akonadi cannot do with this configuration)

when letting Akonadi start its own mysql instance, wait_timeout=31536000 is used

I returned to the default MYSQL server in openSUSE 11.4 and, for being sure, uninstalled all r18 client libraries. Running ldd /usr/lib64/qt4/plugins/sqldrivers/libqsqlmysql.so |grep mysql returns:
libmysqlclient_r.so.16 => /usr/lib64/libmysqlclient_r.so.16 (0x00007fedb1395000)

What I've done:
- Quit KMail
- Stop Akonadi server
- Stop MySQLd
- Reinstalled MySQL 5.1 as described above
- Added to my.cnf in section [mysqld] a line
  wait_timeout = 31536000
- Start MySQLd
- Start Akonadi server
- Start KMail

Unfortunately It is still hanging.

Please attach:
* the 'akonadictl start' output,

and paste:
* the error log content from ~/.local/share/akonadi/db_data

Created attachment 64194
'akonadictl start' output

See attachment and current error log doesn't exist in ~/.local/share/akonadi/db_data.

Currently KMail doesn't hang, I've aöready opened dozens of messages from different Akonadi resources. Strange, but the term: "Reproducible: Sometimes" seems to fit also for me.

... now it is hanging again, but no new error log has appeared.

To be clear (as the original reporter): I'm using the internal mysql database. Sometimes it works, sometimes it doesn't.

Got KMail working after removing all Akonadi user data and recreating the database (just don't know for how long):

$> akonadictl stop
$> rm -rf $HOME/.local/share/akonadi/
$> mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43
Server version: 5.5.16-log Source distribution

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> drop database akonadi;
Query OK, 11 rows affected (0.47 sec)

mysql> create database akonadi;
Query OK, 1 row affected (0.00 sec)

mysql> exit
Bye
$> cat $HOME/.config/akonadi/akonadiserverrc
[%General]
Driver=QMYSQL

[QMYSQL]
Name=akonadi
Host=localhost
StartServer=false
Options="UNIX_SOCKET=/var/run/mysql/mysql.sock"
ServerPath=/usr/bin/mysqld
User=root
Password=do_not_tell

[Debug]
Tracer=null
$> akonadictl start

After those actions KMail shows the selected messages. Will tell you, if it will go wrong again.

KMail hung again with "Retrieving Folder Contents...".
For me it looks like KMail deadlocks when viewing messages while resyncing resources, even if clicking on messages from other resources. In my case it was a resync of a Local KMail folders resource.
After resyncing was done KMail displays all messages again, but very slowly, it takes up to a few seconds to view messages.
I still don't overlook how to best reproduce it, maybe you got a hint for me.

Furthermore there isn't any mail marked as read and even "Mark all as read" over some folder doesn't mark messages read, regardless in which resource (IMAP, local folders, local KMail folders).

Changed in ubuntu-release-notes:
status: New → Fix Committed

I do have the same problem.

With folders or mails that I have imported the message "Retrieving Folder Contents Please wait . . ." is displayed endlessly. I never can read the mail content.

With mails I downloaded from a pop3 server, sometimes I can read the content.

Same here. Problem occurs most often after coming out of suspend to RAM.
BTW: Why is this bug still unconfirmed, while it is confirmed for the ubuntu package? (See bug https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/862483)
I'm having the same issues on my Archlinux machine.

Changed in ubuntu-release-notes:
status: Fix Committed → Fix Released
Changed in akonadi (Ubuntu Oneiric):
status: New → Confirmed

same here. KDE 4.7.3. Clicking on a folder ends up in "retrieving folder contents". akonadictrl stop and then restart it again solved it. let me know if you need more information.

I have exactly the same problem. I am unable to read ANY of my emails !
stop/start akonadi, kmail, linux reboot does not improve anything.

This is a VERY SERIOUS PROBLEM rendering kmail unusable.

Error messages in mysql.err are :

ItemRetrieverException : Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken

Created attachment 66167
mysql.conf from .local/share/akonadi

There are two solutions to this problem:
1. `akonadictl restart` after each resume
2. Stop using kde

Seriously is there anything working in kde4?

Actually, since 4.7.3 things are working better for me. akonadictl restart is not required everytime after suspend. But still sometimes.

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

This also applies to other Akonadi resources, not just those used by kmail. See
bug 287844.

Created attachment 66647
Message display hangup

I also have this bug.

When I click on a message in a folder it isn't displayed at all.

Earlier some of the messages were displayed after a long time
(minutes) and I also had a "KMail Folders: Aborting" progress item
stuck at 0% which won't go away when the "minus" sign was clicked.
(See the attached screenshot).

After I restarted kontact+akonadi the situation got worse an
no message is displayed anymore.

It seems that akonadi is doing something in the background (no clue
what since I did nothing really special except checking mail recently).
In the output I see a lot of error similar to:

akonadi_mixedmaildir_resource_1(24826)/akonadiresource (maildir): "Cannot add email to folder <email address hidden> because there is no email content"
akonadi_mixedmaildir_resource_1(24826)/akonadiresource (maildir): "Cannot add email to folder <email address hidden> because there is no email content"

and later:

request for item 139893 "1323434706.R514.spyro:2,S" failed: "Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
ItemRetrieverException : Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
posting retrieval request for item 139803 there are 1 queues and 0 items in mine
request for item 139803 still pending - waiting
processing retrieval request for item 139803 parts: ("RFC822", "HEAD") of resource: "akonadi_mixedmaildir_resource_1"

In the ps output I see that all the resources seem to be running.
The nepomuk email feeder process is using 66% of the CPU and 200MB
of RAM (but nepomuk is disabled here).

pragma 24828 66.8 2.4 632788 203392 ? Sl 04:37 8:16 /usr/bin/akonadi_nepomuk_email_feeder --identifier akonadi_nepomuk_email_feeder

More digging into this.

When I try to browse the e-mail tree with akonadiconsole I can't access
the contents of the folders (which should belong to a mixedmail resource).
In the debugger window I see:

AkonadiConsole Browser Widget (0x103a430) 8 FETCH 1:* FULLPAYLOAD ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME)
AkonadiConsole Browser Widget (0x103a430) 8 NO Unable to fetch item from backend

The mixedmail resource is running idle (i've attached a gdb session to it and it seems to be sitting mainly inside poll()).

I've managed to view some of the emails by killing the mixedmail resource and (re)starting it manually in the console several times.

From this I've figured out that the mixedmail resource gets stuck on something.

Once I start it kmail shows the messages. Then I browse around the folders to display random messages: after several clicks it starts slowing down and after a few more it gets stuck totally. From that point on no more messages are viewable
(even the ones that were visible before can't be viewed).

When the bug is triggered (that is kmail displays the "Retrieving Folder Contents" message for the first time) the resource stays quiet for some seconds and then spits out a lot of messages similar to this one:

akonadi_mixedmaildir_resource_1(8900)/akonadiresource (maildir) RetrieveItemsJob::Private::fetchChangedResult: Store fetch for changed item "1323661243.R144.spyro" in collection -869 , "" did not return the expected item. error= 102 , "Given folder name is empty"
akonadi_mixedmaildir_resource_1(8900)/akonadiresource (maildir): "Given folder name is empty" collection: Collection ID: -12556 remote ID: ""
   name: ""
   url: KUrl("akonadi:?collection=-12556")
   parent: -869 ""
   resource: ""
   rights: QFlags(0x1|0x2|0x4|0x8|0x10|0x20)
   contents mime type: ()
    CachePolicy:
   inherit: true
   interval: -1
   timeout: -1
   sync on demand: false
   local parts: ()
    CollectionStatistics:
   count: -1
   unread count: -1
   size: -1
akonadi_mixedmaildir_resource_1(8900)/akonadiresource (maildir) RetrieveItemsJob::Private::fetchChangedResult: Store fetch for changed item "1323661243.R175.spyro" in collection -869 , "" did not return the expected item. error= 102 , "Given folder name is empty"

From that point the resource is stuck. The error messages from a previous mail suggest that it doesn't answer at all to DBUS queries.

I haven't found a clear and systematic way to reproduce the issue.
Earlier I've reproduced it by opening a specific folder and clicking an email inside it. But then after a restart the same action didn't trigger the problem.

However it might be something related to timing. In particular I can trigger it very easily shortly after the akonadi server and mysql have been restarted. This is possibly because the caches are empty and take time to be filled. After I kill and restart the mixedmail resource several times, however, the bug hits less and less until I can
browse all my folders and view all my messages.

Weird.

This bug persists also in the 4.8 packages (kubuntu).
KMail doesn't show message contents at all: it just sits there with "Retrieving folder contents". In akonadiconsole there is moderate traffic and mysql+akonadi+resources are taking an average of 200% of CPU (two cores of a quadcore system).

 2397 pragma 20 0 384m 140m 3940 S 135 1.8 549:58.47 mysqld
20992 pragma 20 0 371m 112m 18m S 49 1.4 172:16.93 akonadi_mixedma
20994 pragma 20 0 631m 213m 25m S 18 2.7 64:45.17 akonadi_nepomuk

Ops.. hit submit too fast. Packages of 4.7.4 and not 4.8.

Changed in akonadi:
status: New → Confirmed
Maarten Bezemer (veger) wrote :

Isn't it a problem due to the lost internet connection?
personally, I have problems when the internet connection is lost (suspend, server error, (long taking) wifi reconnection, etc). T solve this problem:
 * click File -> Work offline
 * click File -> Work online

and the connection to the IMAP server is established again. (the missing reconnect option is another bug/issue/wish).
If this indeed solves your problem as well, I think the Release Note needs to be changed, as reconnecting is less 'severe' than restarting akonadi!

Changed in akonadi:
status: Confirmed → Unknown
Rolf Leggewie (r0lf) wrote :

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

Changed in akonadi (Ubuntu Oneiric):
status: Confirmed → Won't Fix

This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.

Changed in akonadi:
status: Unknown → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.