| Summary: | Akonadi on NFS mounted home directories is very fragile | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | krienke |
| Component: | server | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | REOPENED --- | ||
| Severity: | major | CC: | alejandronova, amantia, dvratil, fatalerrors, joerg.steffens, martin.steigerwald, Mathias.Homann, MurzNN, tuju |
| Priority: | NOR | ||
| Version: | 4.6 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 332624 | ||
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? 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? 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... 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. 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... 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. MariaDB reacts flawlessly to those settings. Please, reconsider using those settings as defaults for 4.11 beta 1. (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) @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. 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. Meta bug Bug 332624 - NFS support 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. 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. Reopening, NFS support is still rather fragile :) *** Bug 332624 has been marked as a duplicate of this bug. *** I was feed up with the many issues I had with MariaDB or MySQL. Since I switched to PostgreSQL, it's working like a charm. |
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!