Are you using the default Akonadi configuration ? (use an internal server)

As I said: "I'm using default akonadi config", yes, default is to use internal server

in ~/.local/share/akonadi/ open the mysql.conf file and change (or add):

wait_timeout=31536000

That line is already in. Uncommented.

hm, then unless the mysql process crashes, I'm clueless

Is the mysql process still running when your session is restored ?

Yes, and that mysqld is operate e.g. I've connected to it with a socket, showed databased, selected something), logs from akonadictl restart runned from console:

[22:12 vip@prime:~/.local/share/akonadi]% Error during executing query "SELECT PimItemTable.id, PimItemTable.remoteId, MimeTypeTable.name, ResourceTable.name, PartTable.name, PartTable.datasize FROM PimItemTable INNER JOIN MimeTypeTable ON ( PimItemTable.mimeTypeId = MimeTypeTable.id ) INNER JOIN CollectionTable ON ( PimItemTable.collectionId = CollectionTable.id ) INNER JOIN ResourceTable ON ( CollectionTable.resourceId = ResourceTable.id ) LEFT JOIN PartTable ON ( PimItemTable.id = PartTable.pimItemId AND PartTable.name IN ( :0 ) AND substr(PartTable.name, 1, 4 ) = ( :1 ) ) WHERE ( collectionId = :2 AND ResourceTable.name <> ( :3 ) ) ORDER BY PimItemTable.id ASC" :  "MySQL server has gone away QMYSQL: Unable to execute query"
Error during selection of all records from table "CollectionTable" "MySQL server has gone away QMYSQL: Unable to execute query"
Error during selection of all records from table "CollectionTable" "MySQL server has gone away QMYSQL: Unable to execute query"

Same here with Akonadi 1.6.1, KMail 4.7.1 under Linux. The internal server "goes away" after a suspend/resume cycle. wait_timeout is set to the aforementioned value.

same distribution & mysql version ? (mysql --version)

mysql-5.5.15-3.x86_64
akonadi-1.6.2-1.x86_64
kde4-kdepim-4.7.2-0.1.x86_64
kde4-kdepim-runtime-4.7.2-0.1.x86_64
kde4-kdepim-libs-4.7.2-0.1.x86_64

But as I said, internal mysqld server is working (connected to it with console)

 
I just realised that we (I and Piotr) are, indeed, using the same distribution
- PLD Linux. This *might* mean that we should bug the maintainer first, or at
least wait until someone else confirms this under a different distro.

I have a similar issue: Whenever my computer suspends and wakes at
another place (with another wifi connection), kmail doesn't show new emails
(even after manually checking) even though all imap resources are in connected
state. Email checking works again, when I either restart akonadi or when I switch my imap resources manually offline and then online again in akonadiconsole.

I cannot see a recent error in the aknoadi error log, only a previous error:

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

@K Woelfel which distribution ?

I'm usinge OpenSuSE 11.4, with updated kde:

mysql-community-server-5.1.53-4.7.1.x86_64
akonadi-4.7.2-307.2.x86_64
kdepim4-4.7.2-307.2.x86_64
kdepim4-runtime-4.7.2-4.2.x86_64

same problem with Arch Linux 
KDE 4.7.3
mysql Ver 14.14 Distrib 5.5.17
akonadi 1.6.2

Same here with davmail and external exchange server and an imap akonadi resource on localhost with disconnected option enabled. 

After restart of akonadi, akonadi kontacts davmail again and fetched mails appear in kmail 

Distribution Debian Squeeze/Unstable
kdepim 4.7.4 from kubuntu update oneiric

kmail: 
Qt: 4.8.0
KDE Development Platform: 4.7.4 (4.7.4)
KMail: 4.7.3

Akonadi Server 1.6.2

mysqld  Ver 5.1.49-3 for debian-linux-gnu on i486 ((Debian))

Same here...

Actual archlinux today (06.01.2013)
3.6.10-1-ARCH
KDE 4.9.5

Same problem on Kubuntu 13.04 with KMail 4.11, any fix for this problem?

Not exactly the same problem, but probably related. Or maybe it is the same problem as the symptoms are the same.

First, my System:
Dell Latitude E6410 with 4GB RAM.
Gentoo Linux with Kernel 3.9.5-geek
QT 4.8.4 and KDE-4.10.4 all built from source with gcc-4.7.3 (safe CFLAGS/LDFLAGS settings)

I tried with Mysql-5.1.67 and have now switched to MariaDB-5.5.31. (No, I am not using an embedded server, because I need a running mysql server anyway.)

Now how it is breaking:

IMAP Mail (neither over davmail to exchange nor to a linux IMAP server) does no longer work after a suspend-to-ram -> resume cycle.

This has been like that for quite a while, but there was always a workaround: restart agent in akonadi-console, set it online, go into the settings in kmail and reload the serverside subscriptions for that account.

This is no longer working since KDE-4.10.3, and is not working with KDE-4.10.4.

If I restart the agent(s), they stay offline. If I try to set them online, they stay offline. And the serverside subscription list stays empty and the button to fetch a new list is greyed out.

The only solution is to reboot my laptop.
.. Which makes Akopnadi/Kontact/KMail close to useless for anybody traveling with their machine or using suspension for any good reason.

*** This bug has been confirmed by popular vote. ***

This issue is getting more and more out of hand.

I have tried with a fresh new user, the same happens, so it does not look like an "old-configuration" problem.

The only thing that helps is to remove the imap resource (bye-bye mail filters!) and create a new one.

The last time I wrote that re-booting my laptop helps. This is no longer the case. It helps the first 4 or 5 times the IMAP resource is going out for lunch, but then no longer. I just restarted my laptop, opened contact:

"No connection to IMAP server"
"<name> killed"

Interesting, if I restart the IMAP resource in akonadi-console, I can go into its configuration and refetch the serverside subscription list. But once I exit the configuration I get the "<name> killed" message at once.

The most evil thing is, that I have absolutely no idea how and where to get a backtrace or something like that. All of the debugging tabs in akonadi-console stay clear of any suspicious message. Only unrelated stuff telling me that everything is fine. (as if).

Bug 316107 is about exactly my issues, which are still present.

Could someone test with Akonadi master (or 1.10 branch)? The issue should be fixed there.

(In reply to comment #22)
> Could someone test with Akonadi master (or 1.10 branch)? The issue should be
> fixed there.

I've updated to akonadi server 1.10.2. I'll report back in a few days.

It's not in 1.10.2. Dan meant 'either master or 1.10 git branch'

(In reply to comment #24)
> It's not in 1.10.2. Dan meant 'either master or 1.10 git branch'

Sure? Akonadi worked flawlessly with my IMAP accounts since the upgrade yesterday... But let's see how it goes tomorrow. If it crashes again, I'll go for a live build, ok.

(In reply to comment #25)
> (In reply to comment #24)
> > It's not in 1.10.2. Dan meant 'either master or 1.10 git branch'
> 
> Sure? Akonadi worked flawlessly with my IMAP accounts since the upgrade
> yesterday... But let's see how it goes tomorrow. If it crashes again, I'll
> go for a live build, ok.

Sure! So I am upgrading to a live build now. Did I check out from the correct repo?
git://anongit.kde.org/akonadi

The live build of the akonadi server did improve the situation, my IMAP account didn't go offline, yet. However, every time I send an e-mail I get the following message:

<Account name>: Save failed, server replied: A001889 BAD Error in IMAP command UID: Invalid arguments.

However, the e-mails get sent and are stored in the sent folder like they should.

Ok, so marking this as fixed, feel free to reopen this bug if you run into the problem again.

Regarding the IMAP error, could you please open a separate bug report?

(In reply to comment #28)
> Ok, so marking this as fixed, feel free to reopen this bug if you run into
> the problem again.

That was a bit fast. The Account died again. The main difference between the stable and the live build is, that the live build makes more noise. Instead of just one "<account name> : Killed" message I got several messages about items not being fetchable in offline mode surrounding this "killed" message.

Sorry for the double post, I was too fast when I realized what was going on. damn browser history, really.

I had written that "Bug 316107 is about exactly my issues, which are still present." and wanted to 'move' there as I never had any issue with mysql (which is what _this_ bug is about).

So while answering I was completely on the wrong track thinking to be in the *other* bug report.

Sorry about the noise. However, IMAP is still unusable, even with live built akonadi server. But it has nothing to do with mysql.

I am getting this error again with Akonadi version 1.12.1 under Kubuntu 14.04 with KDE 4.13.1.  After I resume from suspend to RAM, kmail cannot access any mail folders and the Akondai server reports:

DATABASE ERROR:
Error code: 2006
DB error:  "MySQL server has gone away"
Error text: "MySQL server has gone away QMYSQL: Unable to execute query"
Query: "SELECT CollectionTable.id, CollectionTable.remoteId, CollectionTable.remoteRevision, CollectionTable.name, CollectionTable.parentId, CollectionTable.resourceId, CollectionTable.subscribed, CollectionTable.cachePolicyInherit, CollectionTable.cachePolicyCheckInterval, CollectionTable.cachePolicyCacheTimeout, CollectionTable.cachePolicySyncOnDemand, CollectionTable.cachePolicyLocalParts, CollectionTable.queryString, CollectionTable.queryAttributes, CollectionTable.queryCollections, CollectionTable.isVirtual FROM CollectionTable WHERE ( remoteId = :0 AND resourceId = :1 )"
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) Notification source "akonadi_davgroupware_resource_10_12904_hrngU9" now serving: () 
Lost connection to resource "org.freedesktop.Akonadi.Resource.akonadi_davgroupware_resource_10" , discarding cached interface


Restarting the Akondai server recovers from the problem.

An interesting clue is that if I suspend to RAM and then immediately resume (within a minute) the error does not occur and everything is OK.

In my ~/.local/share/akonadi/mysql.conf file has:

# wait 365d before dropping the DB connection (default:8h)
wait_timeout=31536000

I confirm Dean's report, same OS same version.

Confirming bug on KDE 4.14.2, Kubuntu 14.04, linux 3.16.0-28