Bug 182292 - akonadi server start fails on NFS home directory
Summary: akonadi server start fails on NFS home directory
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 4.2
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Volker Krause
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-29 12:43 UTC by Thomas Siegmund
Modified: 2016-09-14 09:04 UTC (History)
12 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 Thomas Siegmund 2009-01-29 12:43:35 UTC
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>&apos; 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.
Comment 1 you-me 2009-09-13 16:25:21 UTC
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. :-(
Comment 2 Stijn Hoop 2009-10-08 09:41:18 UTC
We are seeing the same problem on KDE 4.3 from Fedora 10.
Comment 3 Tobias Koenig 2010-03-16 12:55:23 UTC
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.
Comment 4 Stijn Hoop 2010-03-16 13:45:55 UTC
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...
Comment 5 Tobias Koenig 2010-03-16 14:37:35 UTC
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
Comment 6 Stijn Hoop 2010-03-16 14:43:35 UTC
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.
Comment 7 you-me 2010-03-16 19:53:14 UTC
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.
Comment 8 Thomas Siegmund 2010-03-17 08:21:57 UTC
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
Comment 9 Robert Gerlach 2010-05-23 12:55:50 UTC
It's not fixed. KDE has .kde/socket-<hostname> for sockets, which is linked to /tmp automatically. Please provide such a solution.
Comment 10 Wolfgang Scheicher 2010-08-26 13:51:32 UTC
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
Comment 11 Stijn Hoop 2010-08-27 13:43:14 UTC
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.
Comment 12 Tobias Koenig 2010-09-02 17:19:27 UTC
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.
Comment 13 Marc Schütz 2010-09-06 11:26:17 UTC
(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.
Comment 14 L_F_B 2010-10-05 12:39:11 UTC
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.
Comment 15 david.werner 2010-10-06 15:52:47 UTC
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.
Comment 16 David Jander 2010-11-16 14:58:39 UTC
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!