Version: 1.5.3 (using KDE 4.6.4) OS: Linux akonadi can not start. the path to the socket ist more than 108 charakters. Reproducible: Always Steps to Reproduce: akonadictl start Actual Results: Unable to listen on Unix socket "/afs/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/akonadiserver.socket" Expected Results: akonadi starts and create a socket in /tmp/akonadi-...../... I tried to set the UnixPath in akonadiconnectionrc to the short /tmp/akonadi-..... path, but it still uses the long path with the home dir. Are there any other possibilities (variables, config files, ...) to fix this??
This should have been fixed 7 months ago already. Did you read https://bugs.kde.org/179006 yet ?
(In reply to comment #0) > Version: 1.5.3 This is the version returned by akonadictl --version ?
(In reply to comment #2) > This is the version returned by akonadictl --version ? $ akonadictl --version Akonadi 1.5.3
(In reply to comment #1) it is not related to afs (the afs issue has been fixed as you mentioned), it`s a general issue. My guess: the path length to every socket ist limited to 108 characters. look at /usr/include/sys/un.h ... struct sockaddr_un { __SOCKADDR_COMMON (sun_); char sun_path[108]; /* Path name. */ }; ... and if the length of the HOME directory is rather long, you exceed the limit (as we do). I think the only possibility to workaround is to use the short real "/tmp/.../" pathname. Would be nice to have a function to convert an arbitrary pathname to the "real" (without symlinks, ...) pathname. it`s a general problem which can happen also to other sockets (like mysql.socket). Maybe there are plans to extend the sun_path field (108 char are really not a lot) in the near future. (huhhhh) Would be nice (and at our site necessary) to fix this issue.
I ran into this one on my FreeBSD system where the limit in un.h is 104 characters. As a workaround I shortened my hostname (it's a workstation on my intranet) which reduced the length of the socket name that akonadi uses. It's frustrating and took a while to figure out what was wrong because of the non-specific error message. My akonadictl --version is 1.6.2 and I'm using version 9.0rc3 of the PC-BSD build of FreeBSD.
This bug is still present(and even documented in Akonadi wiki page with a limit of 106 characters) in KDE 4.8.4. I can't believe such a thing still can be there, in a desktop environement intented to be easy to use! Why not removing/replacing the host name in the used path? Because I wonder how we are supposed to do when having a domain name in the computer name... not using KDE?
Setting status to confirmed.
This is present in Akonadi 1.7.2 on OpenSuse 12.2 64bit Confirmed by creating a user with a short enough name and Akonadi works. My normal user (which unfortunately authenticates against AD and consequently has the domain name as a home directory prefix which pushes the socket name to 109 chars) cannot launch akonadiserver.
*** Bug 292323 has been marked as a duplicate of this bug. ***
I think this problem might be related: https://bugs.kde.org/show_bug.cgi?id=320102 and we may have a general problem that affects KDE when the paths to home directories are long. In the case I'm referring to we had /home/DOMAIN/somelonusername plus the fact that we are defining KDETMP=~/tmp/$USER-kde KDEVARTMP=~/tmp/$USER-kde So a socket path could be /home/DOMAIN/somelongusername/tmp/somelongusername-kde/ Since we were having problems we skipped the DOMAIN component for homes. So now we have socket paths such as /home/somelongusernameXX/tmp/somelongusernameXX-kde/ksocket-somelongusernameX/klauncherT31044.slave-socket= which are still like 109 chars long. That is, for some usernames we still have problems that I suspect are socket related. What could be a solution for this?
Git commit 6f6c691451726544487970ef325c71c4ae4a02fa by Christian Mollekopf. Committed on 19/08/2013 at 09:31. Pushed by cmollekopf into branch '1.10'. Use the target of the symlink instead as socket directory. Socket paths must be shorter than 108 characters, and the symlink is quickly beyond that. By using the actual directory this can be avoided. This results in the socket used to start the mysql database, as well as the socket in akonadiconnectionrc being set to the /tmp/ path. REVIEW: 112152 M +2 -2 server/src/utils.cpp http://commits.kde.org/akonadi/6f6c691451726544487970ef325c71c4ae4a02fa