Summary: | akonadi server start fails on NFS home directory | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Thomas Siegmund <siegmund> |
Component: | server | Assignee: | Volker Krause <vkrause> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | david.werner, djander, jreznik, khnz, lars.behrens, MurzNN, rdieter, schuetzm, stijn, tokoe, wolfgang.scheicher, you-me |
Priority: | NOR | ||
Version: | 4.2 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Thomas Siegmund
2009-01-29 12:43:35 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. :-( 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! |