Bug 277839 - akonadiserver.socket path to long
Summary: akonadiserver.socket path to long
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: server (show other bugs)
Version: 4.8
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 292323 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-15 15:06 UTC by markus hetzenecker
Modified: 2013-08-19 09:33 UTC (History)
5 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 markus hetzenecker 2011-07-15 15:06:38 UTC
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??
Comment 1 Christophe Marin 2011-07-15 15:16:13 UTC
This should have been fixed 7 months ago already. Did you read https://bugs.kde.org/179006 yet ?
Comment 2 Christophe Marin 2011-07-15 15:19:53 UTC
(In reply to comment #0)
> Version:           1.5.3

This is the version returned by akonadictl --version ?
Comment 3 markus hetzenecker 2011-07-18 08:44:43 UTC
(In reply to comment #2)
> This is the version returned by akonadictl --version ?
$ akonadictl --version
Akonadi 1.5.3
Comment 4 markus hetzenecker 2011-07-18 09:01:55 UTC
(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.
Comment 5 Shane Brown 2012-01-08 00:41:37 UTC
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.
Comment 6 Stéphane Ascoët 2012-08-31 09:03:27 UTC
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?
Comment 7 Myriam Schweingruber 2012-09-02 07:09:32 UTC
Setting status to confirmed.
Comment 8 Thinus Pollard 2012-11-19 20:09:26 UTC
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.
Comment 9 Christophe Marin 2013-06-08 12:41:02 UTC
*** Bug 292323 has been marked as a duplicate of this bug. ***
Comment 10 gustavo 2013-06-08 13:44:53 UTC
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?
Comment 11 Christian Mollekopf 2013-08-19 09:33:41 UTC
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