[Bug 862483] Re: Unable to read mail after resume due to akonadi hang

Bug Watch Updater 862483 at bugs.launchpad.net
Sat May 26 06:58:29 UTC 2012


Launchpad has imported 32 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=283037.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2011-09-29T15:14:50+00:00 Kde-gj5 wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/0

------------------------------------------------------------------------
On 2011-10-03T11:14:53+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/4

------------------------------------------------------------------------
On 2011-10-03T12:18:03+00:00 Cgiboudeaux wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/5

------------------------------------------------------------------------
On 2011-10-03T12:19:24+00:00 Cgiboudeaux wrote:

> Akonadi uses an external, but local MYSQL server.

Did you configure it ? specially the wait_timeout parameter ?

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/6

------------------------------------------------------------------------
On 2011-10-03T12:24:41+00:00 Renda-krell wrote:

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 - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin

# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50

# The safe_mysqld script
[safe_mysqld]
log-error	= /var/log/mysql/mysqld.log
socket		= /var/run/mysql/mysql.sock

[mysqldump]
socket		= /var/run/mysql/mysql.sock
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[myisamchk]
key_buffer_size = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log        = /var/log/mysqld_multi.log
# user       = multi_admin
# password   = secret

# If you want to use mysqld_multi uncomment 1 or more mysqld sections
# below or add your own ones.

# WARNING
# --------
# If you uncomment mysqld1 than make absolutely sure, that database mysql,
# configured above, is not started.  This may result in corrupted data!
# [mysqld1]
# port       = 3306
# datadir    = /var/lib/mysql
# pid-file   = /var/lib/mysql/mysqld.pid
# socket     = /var/lib/mysql/mysql.sock
# user       = mysql

# [mysqld2]
# port       = 3307
# datadir    = /var/lib/mysql-databases/mysqld2
# pid-file   = /var/lib/mysql-databases/mysqld2/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld2/mysql.sock
# user       = mysql

# [mysqld3]
# port       = 3308
# datadir    = /var/lib/mysql-databases/mysqld3
# pid-file   = /var/lib/mysql-databases/mysqld3/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld3/mysql.sock
# user       = mysql

# [mysqld6]
# port       = 3309
# datadir    = /var/lib/mysql-databases/mysqld6
# pid-file   = /var/lib/mysql-databases/mysqld6/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld6/mysql.sock
# user       = mysql

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/7

------------------------------------------------------------------------
On 2011-10-04T07:52:13+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/8

------------------------------------------------------------------------
On 2011-10-04T07:55:49+00:00 Renda-krell wrote:

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?

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/9

------------------------------------------------------------------------
On 2011-10-04T08:14:38+00:00 Cgiboudeaux wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/10

------------------------------------------------------------------------
On 2011-10-04T09:24:49+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/11

------------------------------------------------------------------------
On 2011-10-04T09:43:48+00:00 Cgiboudeaux wrote:

Please attach:
* the 'akonadictl start' output,

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/12

------------------------------------------------------------------------
On 2011-10-04T09:52:13+00:00 Renda-krell wrote:

Created attachment 64194
'akonadictl start' output

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/13

------------------------------------------------------------------------
On 2011-10-04T09:55:02+00:00 Renda-krell wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/14

------------------------------------------------------------------------
On 2011-10-04T10:06:48+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/15

------------------------------------------------------------------------
On 2011-10-04T10:09:42+00:00 Renda-krell wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/16

------------------------------------------------------------------------
On 2011-10-04T14:23:25+00:00 Kde-gj5 wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/17

------------------------------------------------------------------------
On 2011-10-12T08:03:21+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/18

------------------------------------------------------------------------
On 2011-10-12T08:40:46+00:00 Renda-krell wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/19

------------------------------------------------------------------------
On 2011-10-12T09:00:38+00:00 Renda-krell wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/20

------------------------------------------------------------------------
On 2011-10-14T19:36:19+00:00 menschmeier wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/21

------------------------------------------------------------------------
On 2011-10-15T07:49:30+00:00 Felix-mauch wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/22

------------------------------------------------------------------------
On 2011-11-24T20:31:42+00:00 Kusi wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/23

------------------------------------------------------------------------
On 2011-11-29T02:37:23+00:00 PascalCavy wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/24

------------------------------------------------------------------------
On 2011-11-29T02:39:42+00:00 PascalCavy wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/25

------------------------------------------------------------------------
On 2011-12-01T09:11:19+00:00 Namil wrote:

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

Seriously is there anything working in kde4?

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/26

------------------------------------------------------------------------
On 2011-12-01T09:32:27+00:00 Felix-mauch wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/27

------------------------------------------------------------------------
On 2011-12-02T12:53:38+00:00 Djarvie-h wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/28

------------------------------------------------------------------------
On 2011-12-02T12:56:14+00:00 Djarvie-h wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/29

------------------------------------------------------------------------
On 2011-12-12T03:53:27+00:00 Pragma-n wrote:

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 xxx at yyy.zzz because there is no email content" 
akonadi_mixedmaildir_resource_1(24826)/akonadiresource (maildir): "Cannot add email to folder xxx at yyy.zzz 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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/30

------------------------------------------------------------------------
On 2011-12-12T04:31:51+00:00 Pragma-n wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/31

------------------------------------------------------------------------
On 2011-12-12T06:46:41+00:00 Pragma-n wrote:

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.

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/32

------------------------------------------------------------------------
On 2011-12-26T17:26:16+00:00 Pragma-n wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/33

------------------------------------------------------------------------
On 2011-12-26T17:37:16+00:00 Pragma-n wrote:

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

Reply at: https://bugs.launchpad.net/akonadi/+bug/862483/comments/34

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to akonadi in Ubuntu.
https://bugs.launchpad.net/bugs/862483

Title:
  Unable to read mail after resume due to akonadi hang

To manage notifications about this bug go to:
https://bugs.launchpad.net/akonadi/+bug/862483/+subscriptions




More information about the kubuntu-bugs mailing list