Version: (using Devel) Compiler: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] OS: Linux Installed from: Compiled sources As you can see from the self test there is a problem starting mysql on my system. I noticed that mysql is asked to create its socket at /home/siegmund/.local/share/akonadi/db_misc/mysql.socket but what I find after each failed akonadi start is only /home/siegmund/.local/share/akonadi/db_misc/mysql.socke (without the "t" at the end). Looks like there is a limitation for the path length of sockets on nfs. Starting mysqld manually with --socket on local volumes works with an even longer path or with a shorter path on nfs also works. With the akonadi default path it fails silently. I guess akonadi should be a little bit smarter when deciding where to put it's stuff. Best regards Thomas Akonadi Server Self-Test Report =============================== Test 1: SUCCESS -------- Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration. The following drivers are installed: QSQLITE, QMYSQL3, QMYSQL. Make sure the required driver is installed. File content of '/home/siegmund/.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL [QMYSQL] Name=akonadi User= Password= Options="UNIX_SOCKET=/home/siegmund/.local/share/akonadi/db_misc/mysql.socket" ServerPath=/usr/sbin/mysqld StartServer=true Host=localhost Test 2: SUCCESS -------- MySQL server found. Details: You currently have configured Akonadi to use the MySQL server '/usr/sbin/mysqld'. Make sure you have the MySQL server installed, set the correct path and ensure you have the necessary read and execution rights on the server executable. The server executable is typically called 'mysqld', its locations varies depending on the distribution. Test 3: SUCCESS -------- MySQL server is executable. Details: MySQL server found: /usr/sbin/mysqld Ver 5.0.67 for suse-linux-gnu on i686 (SUSE MySQL RPM) Test 4: ERROR -------- MySQL server log contains errors. Details: The MySQL server error log file '<a href='/home/siegmund/.local/share/akonadi/db_data/mysql.err'>/home/siegmund/.local/share/akonadi/db_data/mysql.err</a>' contains errors. File content of '/home/siegmund/.local/share/akonadi/db_data/mysql.err': 090129 12:00:13 InnoDB: Started; log sequence number 0 43655 090129 12:00:13 [ERROR] Can't start server : Bind on unix socket: Input/output error 090129 12:00:13 [ERROR] Do you already have another mysqld server running on socket: /home/siegmund/.local/share/akonadi/db_misc/mysql.socket ? 090129 12:00:13 [ERROR] Aborting 090129 12:00:13 InnoDB: Starting shutdown... 090129 12:00:14 InnoDB: Shutdown completed; log sequence number 0 43655 090129 12:00:14 [Note] /usr/sbin/mysqld: Shutdown complete Test 5: SUCCESS -------- MySQL server default configuration found. Details: The default configuration for the MySQL server was found and is readable at <a href='/etc/akonadi/mysql-global.conf'>/etc/akonadi/mysql-global.conf</a>. File content of '/etc/akonadi/mysql-global.conf': # # Global Akonadi MySQL server settings, # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris@mysql.com> # [mysqld] skip_grant_tables skip_networking # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled #sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat #sql_mode=strict_trans_tables # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # case-insensitive table names, avoids trouble on windows lower_case_table_names=1 character_set_server=latin1 collation_server=latin1_general_ci table_cache=200 thread_cache_size=3 log_bin=mysql-bin expire_logs_days=3 #sync_bin_log=0 # error log file name, relative to datadir log_error=mysql.err log_warnings=2 # log all queries, useful for debugging but generates an enormous amount of data #log=mysql.full # log queries slower than n seconds, log file name relative to datadir log_slow_queries=mysql.slow long_query_time=1 # log queries not using indices, debug only, disable for production use log_queries_not_using_indexes=1 # maximum blob size max_allowed_packet=32M max_connections=256 # makes sense when having the same query multiple times # makes no sense with prepared statements and/or transactions query_cache_type=0 query_cache_size=0 innodb_file_per_table=1 innodb_log_buffer_size=1M innodb_additional_mem_pool_size=1M # messure database size and adjust # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); innodb_buffer_pool_size=80M # size of average write burst, keep Innob_log_waits small, keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) innodb_log_file_size=64M innodb_flush_log_at_trx_commit=2 Test 6: SKIP -------- MySQL server custom configuration not available. Details: The custom configuration for the MySQL server was not found but is optional. Test 7: SUCCESS -------- MySQL server configuration is usable. Details: The MySQL server configuration was found at <a href='/home/siegmund/.local/share/akonadi/mysql.conf'>/home/siegmund/.local/share/akonadi/mysql.conf</a> and is readable. File content of '/home/siegmund/.local/share/akonadi/mysql.conf': # # Global Akonadi MySQL server settings, # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris@mysql.com> # [mysqld] skip_grant_tables skip_networking # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled #sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat #sql_mode=strict_trans_tables # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # case-insensitive table names, avoids trouble on windows lower_case_table_names=1 character_set_server=latin1 collation_server=latin1_general_ci table_cache=200 thread_cache_size=3 log_bin=mysql-bin expire_logs_days=3 #sync_bin_log=0 # error log file name, relative to datadir log_error=mysql.err log_warnings=2 # log all queries, useful for debugging but generates an enormous amount of data #log=mysql.full # log queries slower than n seconds, log file name relative to datadir log_slow_queries=mysql.slow long_query_time=1 # log queries not using indices, debug only, disable for production use log_queries_not_using_indexes=1 # maximum blob size max_allowed_packet=32M max_connections=256 # makes sense when having the same query multiple times # makes no sense with prepared statements and/or transactions query_cache_type=0 query_cache_size=0 innodb_file_per_table=1 innodb_log_buffer_size=1M innodb_additional_mem_pool_size=1M # messure database size and adjust # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); innodb_buffer_pool_size=80M # size of average write burst, keep Innob_log_waits small, keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) innodb_log_file_size=64M innodb_flush_log_at_trx_commit=2 Test 8: SUCCESS -------- akonadictl found and usable Details: The program '/usr/bin/akonadictl' to control the Akonadi server was found and could be executed successfully. Result: Akonadi 1.1.1 Test 9: ERROR -------- Akonadi control process not registered at D-Bus. Details: The Akonadi control process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup. Test 10: ERROR -------- Akonadi server process not registered at D-Bus. Details: The Akonadi server process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup. Test 11: SKIP -------- Protocol version check not possible. Details: Without a connection to the server it is not possible to check if the protocol version meets the requirements. Test 12: ERROR -------- No resource agents found. Details: No resource agents have been found, Akonadi is not usable without at least one. This usually means that no resource agents are installed or that there is a setup problem. The following paths have been searched: '/usr/share/akonadi/agents'. The XDG_DATA_DIRS environment variable is set to '/usr/share:/etc/opt/kde3/share:/opt/kde3/share', make sure this includes all paths where Akonadi agents are installed to. Directory listing of '/usr/share/akonadi/agents': distlistresource.desktop icalresource.desktop imaplibresource.desktop kabcresource.desktop kcalresource.desktop localbookmarksresource.desktop maildirresource.desktop mailthreaderagent.desktop nepomukcontactfeeder.desktop nepomukemailfeeder.desktop nepomuktagresource.desktop nntpresource.desktop strigifeeder.desktop vcarddirresource.desktop vcardresource.desktop Environment variable XDG_DATA_DIRS is set to '/usr/share:/etc/opt/kde3/share:/opt/kde3/share' Test 13: ERROR -------- Current Akonadi server error log found. Details: The Akonadi server did report error during startup into <a href='/home/siegmund/.local/share/akonadi/akonadiserver.error'>/home/siegmund/.local/share/akonadi/akonadiserver.error</a>. File content of '/home/siegmund/.local/share/akonadi/akonadiserver.error': "[ 0: akonadiserver(_Z10kBacktracev+0x35) [0x8052bf5] 1: akonadiserver [0x80530d6] 2: [0xffffe400] 3: [0xffffe430] 4: /lib/libc.so.6(gsignal+0x50) [0xb77ee990] 5: /lib/libc.so.6(abort+0x188) [0xb77f02c8] 6: /usr/lib/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x95) [0xb7b668d5] 7: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xc4) [0x8054444] 8: /usr/lib/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9e) [0xb7bf3c6e] 9: /usr/lib/libQtCore.so.4 [0xb7c00c2e] 10: /usr/lib/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x68) [0xb7c00f28] 11: /usr/lib/libakonadiprivate.so.1(_ZN6QDebugD1Ev+0x51) [0xb7f0c861] 12: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0x1a4e) [0xb7f1560e] 13: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServerC1EP7QObject+0x72) [0xb7f17462] 14: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer8instanceEv+0x56) [0xb7f18566] 15: akonadiserver(main+0x313) [0x804d0f3] 16: /lib/libc.so.6(__libc_start_main+0xe5) [0xb77da705] 17: akonadiserver [0x804cd11] ] " Test 14: ERROR -------- Previous Akonadi server error log found. Details: The Akonadi server did report error during its previous startup into <a href='/home/siegmund/.local/share/akonadi/akonadiserver.error.old'>/home/siegmund/.local/share/akonadi/akonadiserver.error.old</a>. File content of '/home/siegmund/.local/share/akonadi/akonadiserver.error.old': "[ 0: akonadiserver(_Z10kBacktracev+0x35) [0x8052bf5] 1: akonadiserver [0x80530d6] 2: [0xffffe400] 3: [0xffffe430] 4: /lib/libc.so.6(gsignal+0x50) [0xb783d990] 5: /lib/libc.so.6(abort+0x188) [0xb783f2c8] 6: /usr/lib/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x95) [0xb7bb58d5] 7: akonadiserver(_ZN15FileDebugStream9writeDataEPKcx+0xc4) [0x8054444] 8: /usr/lib/libQtCore.so.4(_ZN9QIODevice5writeEPKcx+0x9e) [0xb7c42c6e] 9: /usr/lib/libQtCore.so.4 [0xb7c4fc2e] 10: /usr/lib/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x68) [0xb7c4ff28] 11: /usr/lib/libakonadiprivate.so.1(_ZN6QDebugD1Ev+0x51) [0xb7f5b861] 12: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer20startDatabaseProcessEv+0x1a4e) [0xb7f6460e] 13: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServerC1EP7QObject+0x72) [0xb7f66462] 14: /usr/lib/libakonadiprivate.so.1(_ZN7Akonadi13AkonadiServer8instanceEv+0x56) [0xb7f67566] 15: akonadiserver(main+0x313) [0x804d0f3] 16: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7829705] 17: akonadiserver [0x804cd11] ] " Test 15: SUCCESS -------- No current Akonadi control error log found. Details: The Akonadi control process did not report any errors during its current startup. Test 16: SUCCESS -------- No previous Akonadi control error log found. Details: The Akonadi control process did not report any errors during its previous startup.
I had the same problem. Home directory on a NAS mounted via NFS. KDE 4.3 with Kubuntu 9.04. Moving ~/.local/share/akonadi and ~/.config/akonadi to a machine local drive and linking it to the NFS home directory as a workaround for a single machine works, but is not the desired solution. Once I work from another machine the problem will be back - and my akonadi data not available. :-(
We are seeing the same problem on KDE 4.3 from Fedora 10.
The problem is, that NFS does not support unix pipes which are used by MySQL and Akonadi for communication. To fix this, just add the following two lines to your $HOME/.config/akonadi/akonadiserverrc [Connection] SocketDirectory=/tmp/akonadi-myuser Then Akonadi will create the unix pipes under this directory.
So you are proposing we create / alter that file for our ~300 users, and keep it up to date for new users? I guess you can consider it fixed if so...
Hej Stijn, I don't see any other option... NFS/ASF do not support Unix pipes but we and several other projects use Unix pipes... The only solution for this problem is to provide customizable socket paths. Ciao, Tobias
OK, that previous comment wasn't really constructive. My apologies, but we've had a few mysterious KDE crashes due to this and I thought an NFS homedirectory setup would not be so uncommon for large(ish) sites. Anyway... Given that $ stat -f -c %T $HOME can give you the answer what type the filesystem is, isn't it possible to let Akonadi choose from a set of default paths, try them all to see which one is local, and put the socket on that? I'd suggest $HOME/.local /tmp/$USER /var/tmp/$USER as possible candidates. Maybe some XDG spec has even more suggestions, but I don't know. In the meantime I guess we'll implement your proposal.
Hi Tobias, it workes for me since a while now. I removed all akonadi directories and files I could find and then it created the file ~/.config/akonadi/akonadiserverrc for me, which does the trick, see below. Adding the lines you suggested also works - once I created the directory specified (/tmp/akonadi-myuser). I use Kubunto 9.10 with the ppa repositories (deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu karmic main universe multiverse restricted). Thanks for the hint. Regards, Thomas ~/.config/akonadi/akonadiserverrc: [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false [QMYSQL] Name=akonadi User= Password= Options="UNIX_SOCKET=/home/thomas/.local/share/akonadi/db_misc/mysql.socket" ServerPath=/usr/sbin/mysqld-akonadi StartServer=true Host= [Debug] Tracer=null Mail von Tobias Koenig <tokoe@kde.org> am 16.03.2010: https://bugs.kde.org/show_bug.cgi?id=182292 Tobias Koenig <tokoe@kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |tokoe@kde.org Resolution| |FIXED --- Comment #3 from Tobias Koenig <tokoe kde org> 2010-03-16 12:55:23 --- The problem is, that NFS does not support unix pipes which are used by MySQL and Akonadi for communication. To fix this, just add the following two lines to your $HOME/.config/akonadi/akonadiserverrc [Connection] SocketDirectory=/tmp/akonadi-myuser Then Akonadi will create the unix pipes under this directory.
Wow, one year and two KDE releases to come up with a workaround instead of a bug fix. This gives a lot of confidence into the new KDE PIM. Or, to give it a more positive spin, I strongly support #6. Cheers, Thomas
It's not fixed. KDE has .kde/socket-<hostname> for sockets, which is linked to /tmp automatically. Please provide such a solution.
I'm confused. Is this fixed or not, and if - in which version? I have tested with kde 4.4.5 from debian squeeze and i fail to start akonadi, eaven with the workarounds described by #7
Wolfgang: unfortunately we still run Fedora 12 but at least there it is NOT fixed. KDE 4.4.5. In fact, just today I had to help a kmail user with a twice-a-day hang due to the fact that kmail couldn't contact the local akonadi server. Not to mention that he wants to login to another system from home as well, so putting the akonadi data on a local disk means that he has two copies of the whole database. I'm not entirely sure why "having a home directory on NFS/AFS" is considered an edge case, but apparently it is.
To bring some clarification: The Akonadi server is desktop environment agnostic per design and therefor doesn't use any kde libraries. For this reason depending on the existence of a .kde/socket-<hostname> directory won't work. We have to find another solution here which involves some more work than it looks like at the first glance.
(In reply to comment #12) > To bring some clarification: The Akonadi server is desktop environment agnostic > per design and therefor doesn't use any kde libraries. For this reason > depending on the existence of a .kde/socket-<hostname> directory won't work. > > We have to find another solution here which involves some more work than it > looks like at the first glance. Then please at least reopen this bug. Considering that Kontact is a groupware suite, and NFS home directories are fairly common in organisations that require groupware functionality, it would even be reasonable to mark this bug as a BLOCKER.
We are using nfs here too. To pass on the work to the user (admins) seems not a very decent idea to me. IMO akonadi should provide an own solution to deal with net mounted ~ directories. Neither changing config files for each user, nor setting up an extra sql server for an abstraction layer which isn't needed here, makes me enthusiastic be any means.
please fix that. It seems to me that NFS users can't get use KDE longer properly. Many scientific working groups use NFS. To setup a non local mysql server would also create new security risc, beside it is not functional cache. Not all environments have the opportunity to setup non local mysql servers for their users as fileservice get outsourced.
Please reopen this bug. It's KDE-4.4.2 (Kubuntu 10.04) for me and akonadi still does not even start. I tried all workarounds/proposed solutions I could find here and elsewhere, but it won't start (NFS home). What's worse now is that KMail won't work without akonadi anymore so I had to ditch KMail. If KDE continues this pace, there will be not much left of it worth using for me. I have been using KDE since 1.0, loved 3.5, was shocked by 4.0, but patient to wait for improvements and bugfixes (I am a _very_ patient person), but I keep noticing that instead of improving (like 1.x, 2.x and 3.x series did), 4.x is getting worse with every release. I loved KMail in 3.5.10, it was fast and powerful. In 4.2 it sent slow and buggy and in 4.4 it stopped working altogether. Worst thing is: Bug reports such as this one still get ignored/dismissed after more than a year. Great!