[Kde-pim] QLocalSocket::connectToServer: Invalid name

[Daniel Vrátil]

On Thursday 17 of April 2014 13:28:37 Patrick Ohly wrote:
> On Mon, 2014-03-31 at 15:15 +0200, Patrick Ohly wrote:
> > Hello!
> > 
> > Occasionally, my nightly testing fails with libakonadi hanging in a
> > process and blocking all progress until testing aborts and kills the
> > processes.
> > 
> > The error log then shows:
> > 
> > syncevolution(15975)/libakonadi Akonadi::SessionPrivate::socketError:
> > Socket error occurred: "QLocalSocket::connectToServer: Invalid name"
> > QDBusConnection: session D-Bus connection created before
> > QCoreApplication. Application may misbehave. kres-migrator: cannot
> > connect to X server
> > QDBusConnection: session D-Bus connection created before QCoreApplication.
> > Application may misbehave. kres-migrator: cannot connect to X server
> > 
> > It does not happen when I run the same test manually, therefore I don't
> > have further information.
> > 
> > There is an open bug about this:
> > https://bugs.kde.org/show_bug.cgi?id=229534
> 
> With extended logging, I get additional information:
> 
> syncevolution(15445)/libakonadi Akonadi::SessionPrivate::init: ""
> syncevolution(15445)/libakonadi Akonadi::Firstrun::Firstrun:
> syncevolution(15445)/libakonadi Akonadi::Firstrun::Firstrun: ()
> syncevolution(15445)/libakonadi Akonadi::SessionPrivate::reconnect:
> connectToServer "/tmp/akonadi-nightly.Fm3Py5/akonadiserver.socket"
> syncevolution(15445)/libakonadi Akonadi::SessionPrivate::socketError:
> Socket error occurred: "QLocalSocket::connectToServer: Invalid name"
> syncevolution(15445)/libakonadi Akonadi::Firstrun::~Firstrun: done
> 
> The problem in my case is probably that I have multiple, independent
> Akonadi test sessions running which end up sharing this particular path
> in /tmp, because it seems to be the same for each "akonadictl
> start" (for me - see below).
> 
> There are two different akonadiserver processes, both with the same socket
> open:
> 
> $ lsof -p 11202 | grep tmp/akonadi
> akonadise 11202 nightly   12u  unix 0x0000000000000000      0t0 12065884
> /tmp/akonadi-nightly.Fm3Py5/akonadiserver.socket $ lsof -p 11354 | grep
> tmp/akonadi
> akonadise 11354 nightly   12u  unix 0x0000000000000000      0t0 12066062
> /tmp/akonadi-nightly.Fm3Py5/akonadiserver.socket
> 
> Errors in this case are not surprising...

That should never happen. The only situation I can imagine is that you are 
running the tests in separated DBus sessions, so when they call akonadictl 
start, Akonadis don't see each other and assume they are the only one running.

As I already pointed out in some previous email, use Akonadi instances if you 
want to run multiple tests in parallel (akonadictl --instance randomstring 
start), to make sure each Akonadi is isolated from the others on all levels.

For more comfort, there's the akonaditest runner in kdepimlibs (in KDE >= 
4.12), which takes care of correctly setting up isolated environment, 
executing a test case and then cleaning all up again. It might save you a lot 
of trouble.

> I noticed that "akonadictl start" indirectly creates
> $XDG_CONFIG_HOME/akonadi/akonadiconnectionrc and that "akonadictl stop"
> removes it. strace tells me that it is akonadiserver itself which does
> that.
> 
> Is this a user-configurable file? If not, then $XDG_CACHE_HOME or (if
> available) $XDG_RUNTIME_DIR seem more appropriate.
> 
> Further digging in the strace output shows that akonadiserver takes the
> fixed /tmp/akonadi-nightly.Fm3Py5 from
> $XDG_DATA_HOME/akonadi/socket-<hostname> which (in my case) was the same
> symlink for all my tests sessions. When I remove it, it gets created by
> akonadiserver pointing to a unique name => problem (probably) solved for
> me.
> 
> However, why is akonadiserver leaving that symlink around and only
> removes akonadiconnectionrc? Is the reuse of the previous path
> intentional or accidental?

The reuse is intentional. It is primarily stored in akonadiserverrc.

Dan

> 
> Bye, Patrick
> 
> 
> 
> _______________________________________________
> KDE PIM mailing list kde-pim at kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140417/38848701/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/