Bug 275261 - Akonadi on NFS mounted home directories is very fragile
Summary: Akonadi on NFS mounted home directories is very fragile
Status: REOPENED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 4.6
Platform: OpenSUSE Linux
: NOR major with 62 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 332624 (view as bug list)
Depends on:
Blocks: 332624
  Show dependency treegraph
 
Reported: 2011-06-09 08:56 UTC by krienke
Modified: 2022-05-04 13:16 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krienke 2011-06-09 08:56:52 UTC
Version:           4.6 (using KDE 4.6.3) 
OS:                Linux

In our environment every user has his home directory on a NFS mounted directory. As a consequence the akonadi database (in ~/.local/share/akonadi) is located on NFS as well. Basically this works.

However if the computer hangs and has to be restarted or the system does not wake up from a suspend to disk and has to rebooted or quite any other crash that might happen turns akonadi permanently unusable because the mysql database seems to be completely broken so it cannot be repaired when akonadi starts (see attached error log below). The only way to repair I know is to remove the broken database or to restore an older version from my personal backup.

For a regular user  without deeper knowlegde about kde and akonadi such a crash renders his KDE session quite unusable: no kmail, no knode and no kontact. 

The big problem: KDE does *not* offer *any options* for the user to get out of this situation. This probably will cause frustation.

I think KDE must offer some help if the database is broken to get back into a usable state, or there must be an option to live without akonadi if it fails and thus blocks the most important applications for daily work  like kmail or korganizer.

A possible solution would be to offer the user at least a way to restore a backup of the akonadi database, which of course means there must be an automatic backup before. The user should be able to configure where the backup should be located.

Reproducible: Sometimes

Steps to Reproduce:
crash the system by any means, sometimes it is already enough to terminate a KDE session by CTRL-ALT-BACKSPACE .

Actual Results:  
Akonadi is not running and so preventing kdepim-apps from starting


The akonadi errorlog:

The akonadi errorlog:

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)
search paths:  ("/bin", "/usr/bin", "/sbin", "/usr/sbin", "/opt/kde3/bin", "/opt/kde/bin", "/opt/gnome/bin", "/usr/local/bin", "/usr/local/sbin", "/opt/Acrobat3/bin", "/import/sw/frame5.5.6/bin", "/home/krienke/bin/unknown-linux", "/home/krienke/bin", ".", "/usr/sbin", "/usr/local/sbin", "/usr/local/libexec", "/usr/libexec", "/opt/mysql/libexec", "/opt/local/lib/mysql5/bin", "/opt/mysql/sbin") 
Found mysql_install_db:  "/usr/bin/mysql_install_db" 
Found mysqlcheck:  "/usr/bin/mysqlcheck" 
Database process exited unexpectedly during initial connection!
executable: "/usr/sbin/mysqld"
arguments: ("--defaults-file=/home/krienke/.local/share/akonadi//mysql.conf", "--datadir=/home/krienke/.local/share/akonadi/db_data/", "--socket=/home/krienke/.local/share/akonadi/socket-bliss/mysql.socket")
stdout: ""
stderr: ""
exit code: 1
process error: "Unknown error"
"[
0: akonadiserver(_Z11akBacktracev+0x39) [0x44dd19]
1: akonadiserver() [0x44e282]
2: /lib64/libc.so.6(+0x32b30) [0x7fe9bedd9b30]
3: /lib64/libc.so.6(gsignal+0x35) [0x7fe9bedd9ab5]
4: /lib64/libc.so.6(abort+0x186) [0x7fe9beddafb6]
5: /usr/lib64/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x74) [0x7fe9c0abc924]
6: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xab) [0x45054b]
7: /usr/lib64/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x77) [0x7fe9c0b4a747]
8: /usr/lib64/libQtCore.so.4(+0x106ac6) [0x7fe9c0b52ac6]
9: /usr/lib64/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x3b) [0x7fe9c0b5b9ab]
10: akonadiserver(_ZN6QDebugD1Ev+0x4b) [0x4492db]
11: akonadiserver(_ZN13DbConfigMysql19startInternalServerEv+0x1a18) [0x4d5f58]
12: akonadiserver(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0xd8) [0x450958]
13: akonadiserver() [0x4535c8]
14: akonadiserver(_ZN7Akonadi13AkonadiServer8instanceEv+0x35) [0x454be5]
15: akonadiserver(main+0x21f) [0x4486cf]
16: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fe9bedc5bfd]
17: akonadiserver() [0x4483b9]
]
"
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)
"akonadiserver" crashed too often and will not be restarted!
Comment 1 András Manţia 2011-11-13 19:04:13 UTC
An user suggested this settings:

sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

in .local/share/akonadi/mysql.conf

Can you please test it if it helps?
Comment 2 András Manţia 2011-11-14 07:09:05 UTC
Can you please report the problem also on http://bugs.mysql.com giving information about the setup you have and the error logs printed out from mysql itself?
Comment 3 Mathias Homann 2011-11-25 06:49:35 UTC
I tried those settings....

they make akonadi crash after start even with a clean database.


I believe the root issue here is using a mysql database as storage for a PIM.

can't you people see outside the small "one personal computer, one user" world?

Imagine this in a thin client environment where every user is effectively logged on on the same big server... and runs his or her own mysql server just to store a few addresses...
Comment 4 András Manţia 2011-11-25 07:00:39 UTC
I'm sorry to hear it didn't work.
For multi user installation, there is a possibility to use a system wide mysql server. 
This is written down here https://wiki.archlinux.org/index.php/KDE#Configuring_Akonadi_to_use_MySQL_Server_running_on_the_System (not tested by myself though).

It is also possible to use postgres or you can try sqlite as well, but I do not recommend sqlite.
Comment 5 Mathias Homann 2011-11-25 08:23:20 UTC
systemwide mysql will be my next step.

feature request: make it possible to use *one* database for *all* users in a network, accessible with *the same* db credentials, so that one network wide akonadirc can be deployed automatically (maybe even throuigh NIS on startup).

Additionally, make it possible to configure non-cached datasources. When a company has LDAP set up (Active Directory) I *want* the data to come from the server every time...
Comment 6 András Manţia 2011-11-25 08:32:11 UTC
For the first, I created a new issue. The second I'm not sure I understand. Can you create a new issue for Akonadi and server component, describing what exactly you wish? Even right now it is possible to configure the cache policy for Akonadi resources (Akonadiconsole or KMail, right click on the main folder, properties, Retrieval, set the Keep message bodies for... ), but I'm not sure this is what you mean, so it is better if you explain it in a separate report.
Comment 7 Alejandro Nova 2013-06-11 04:35:36 UTC
MariaDB reacts flawlessly to those settings. Please, reconsider using those settings as defaults for 4.11 beta 1.
Comment 8 Christophe Marin 2013-06-11 08:03:18 UTC
(In reply to comment #7)
> MariaDB reacts flawlessly to those settings. Please, reconsider using those
> settings as defaults for 4.11 beta 1.

That's not a great idea for most users.

- sync_binlog has a speed impact and could possibly cause extra power consumption on laptops
- innodb_flush_log_at_trx_commit possibly causes innodb corruption on some FS/hardware/OS

References: 
http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_sync_binlog
http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit (read the 'caution' section)
Comment 9 Alejandro Nova 2013-06-11 19:05:40 UTC
@Christophe: If I understood well:
1. sync_binlog introduces a performance penalty.
2. innodb_flush_log_at_trx can't fully work since the operating system cache can intervene, overriding MySQL behavior.

However, a) I'm prepared to pay that penalty if that means a reduced likelihood of database corruption (which introduces a MUCH LARGER performance penalty later) and b) those options don't eliminate possible DB corruptions, but greatly reduce them. So, it seems wise to introduce those options as defaults, unless you are 100% sure your system won't crash.
Comment 10 Daniel Vrátil 2013-12-06 14:48:40 UTC
If I'm reading this correctly:

1) MySQL via NFS does not work: pretty much an upstream issue and there's nothing we can do about it.

2) Request to support system-wide MySQL with global credentials: Akonadi allows to connect to a remote MySQL server already, but not with the same credentials for everyone (reported as bug #287515). I'm not sure we want to support such case though.

3) MariaDB copes better with NFS when using some special settings options -> we can add them to our mysql.conf (commented out by default), with instruction to enable them when running Akonadi on NFS.

If nobody objects, I'd close this bug as FIXED after adding the options to mysql.conf, since the original objection is an upstream issue and the MariaDB options seem to fix the problem.
Comment 11 Martin Steigerwald 2014-03-26 11:04:38 UTC
Meta bug Bug 332624 - NFS support
Comment 12 Denis Kurz 2016-09-24 20:42:05 UTC
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.
Comment 13 Denis Kurz 2017-01-07 22:31:05 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.
Comment 14 Daniel Vrátil 2017-02-23 19:10:40 UTC
Reopening, NFS support is still rather fragile :)
Comment 15 Jonathan Marten 2021-02-04 20:32:06 UTC
*** Bug 332624 has been marked as a duplicate of this bug. ***