Summary: | kmail2/akonadi fail to send messages, kmail long uptime | ||
---|---|---|---|
Product: | [Applications] kmail2 | Reporter: | Francesco Riosa <vivo75+kde> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | cruzki123, gspr, hatem.masmoudi, martin+kde |
Priority: | NOR | ||
Version: | 2.0.96 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Francesco Riosa
2011-06-02 14:19:51 UTC
I seem to be affected too by this. A clean new config, google imap works great, but sending doesn't. Restarting kmail isn't enough, I have to completely restart akonadi to send an email (akonadictl restart). Seeing that I'm also on Gentoo (kdepim 4.6.1); could it be related to the fact that the default config (which I use) has sqlite as backend? (In reply to comment #1) > I seem to be affected too by this. A clean new config, google imap works great, > but sending doesn't. Restarting kmail isn't enough, I have to completely > restart akonadi to send an email (akonadictl restart). Seeing that I'm also on > Gentoo (kdepim 4.6.1); could it be related to the fact that the default config > (which I use) has sqlite as backend? If my analisys of a timeout in mysql connection is correct, no it cannot be related ;) The important part of the report seems to be this line:
> MySQL server has gone away QMYSQL: Unable to execute query"
Can you define long inactivity please ?
If the sql instance goes down, you can probably find more clues in the mysql.err and mysql.err.old files in ~/.local/share/akonadi/db_data/ directory
(In reply to comment #3) > The important part of the report seems to be this line: > > > MySQL server has gone away QMYSQL: Unable to execute query" > > Can you define long inactivity please ? mysql> SELECT @@interactive_timeout; +-----------------------+ | @@interactive_timeout | +-----------------------+ | 28800 | +-----------------------+ 1 row in set (0.00 sec) > If the sql instance goes down, you can probably find more clues in the > mysql.err and mysql.err.old files in ~/.local/share/akonadi/db_data/ directory the mysql instance goes down by design, well at least the session opened by clients goes down, even if the SQL server stays up. wrong assumption I'm afraid, this setting doesn't matter for Akonadi. Try SELECT @@wait_timeout instead (which should return 1296000) This is the important timeout for TCP and socket connections. (In reply to comment #5) > wrong assumption I'm afraid, this setting doesn't matter for Akonadi. > Try SELECT @@wait_timeout instead (which should return 1296000) > > This is the important timeout for TCP and socket connections. I'm using a system wide mysql instance for Akonadi, does it matter? mysql> SELECT @@wait_timeout; +----------------+ | @@wait_timeout | +----------------+ | 28800 | +----------------+ 1 row in set (0.00 sec) well, yes, using an external mysql instance supposes that you configure your mysql server first. Akonadi cannot do that for external servers for obvious reasons. You can find the special settings used when Akonadi starts its own mysql instance there: https://projects.kde.org/projects/kdesupport/akonadi/repository/revisions/master/entry/server/src/storage/mysql-global.conf (In reply to comment #7) > well, yes, using an external mysql instance supposes that you configure your > mysql server first. Akonadi cannot do that for external servers for obvious > reasons. > > You can find the special settings used when Akonadi starts its own mysql > instance there: >https://projects.kde.org/projects/kdesupport/akonadi/repository/revisions/master/entry/server/src/storage/mysql-global.conf Thank you for discussing and showing the Akonadi default configuration, I see the only ones that are _really_ required are ATM max_allowed_packet=32M wait_timeout=1296000 with possibly the addition of max_connections=256 the others are there just for performance reasons or can be set from the client disclaimer, I'm versus any kde-sc starting whatever database server, because IMHO it's a bad thing (I'm trying to convince DigiKam developers to don't do that too), so possibly the following is a bit of a rant but there are also suggestions, so I'll keep writing. Setting the timeout to 15 days is just try to hide the problem, there are multiple reasons that can bring a database connection down, clients must simply be resilient to that. Developers should test with timeouts no longer than 60 seconds. A desktop environment should not try to start a database, sqlite is the one that does embedding well. For their inherent complexity database servers should be started by the same scripts that start kdm, distributions have the expertise to do that and you (kde) should simply impose them a minimum. simply akonadi at startup should test a minimal safe values for a restricted number of variables (which don't include timeouts imho) then if the database server is down or does not meet the requirements it should warn the user. Thanks for reading (if you reached this ;) P.S. feel free to close the bug if you wish have a look at "Comment #16 - https://bugs.kde.org/show_bug.cgi?id=278020 ". for me this correct the problem of kmail2 (kde 4.7.0) After checking there is another bug: when setting config to [Agent] Online=true I success to send Email, but all emails are not forwarded to the server even if the Sent folder is on the server ! (In reply to comment #11) > [...] > > I success to send Email, but all emails are not forwarded to the server even if > the Sent folder is on the server ! Please do not mix issues. Create a new bug report for this one I disagree. Wontfix is not the correct resolution. It's working with the default Akonadi settings. it's working for a maximum of 15 days which is 1/4 of the medium uptime in my office. Hopefully if I find the time to dig it further and to provide some patches we can return on this with and find some kind of agreement. Best, Francesco it's 15 days *without activity* Git commit c5f3670fcd4d4d08d1af8d004c82d604e6df8bd9 by Christophe Giboudeaux. Committed on 09/09/2011 at 17:13. Pushed by cgiboudeaux into branch 'master'. Raise the timeout value to 365d CCBUG:274750 M +1 -1 server/src/storage/mysql-global-mobile.conf M +1 -1 server/src/storage/mysql-global.conf http://commits.kde.org/akonadi/c5f3670fcd4d4d08d1af8d004c82d604e6df8bd9 Git commit 26d031b4f32e8eaa99e1a53cc1c62a90a4899299 by Volker Krause, on behalf of Christophe Giboudeaux. Committed on 09/09/2011 at 17:13. Pushed by vkrause into branch '1.6'. Raise the timeout value to 365d CCBUG:274750 M +1 -1 server/src/storage/mysql-global-mobile.conf M +1 -1 server/src/storage/mysql-global.conf http://commits.kde.org/akonadi/26d031b4f32e8eaa99e1a53cc1c62a90a4899299 I don't think it feels right for a system to require manual intervention every n time units, no matter if n is 60 seconds or 365 days. Or is the patch meant as a temporary stopgap solution? |