[Kde-pim] configuring Akonadi server

Mon Mar 17 08:36:38 GMT 2014

On Friday 14 of March 2014 17:30:02 Patrick Ohly wrote:
> On Thu, 2014-03-13 at 17:29 +0100, Daniel Vrátil wrote:
> > On Wednesday 12 of March 2014 14:41:46 Patrick Ohly wrote:
> > > On Wed, 2014-03-12 at 14:26 +0100, Patrick Ohly wrote:
> > > > On Tue, 2014-03-11 at 16:36 +0100, Daniel Vrátil wrote:
> > > > > On Tuesday 11 of March 2014 16:08:36 Kevin Krammer wrote:
> > <snip>
> > 
> > > > That helps to get "akonadictl start" working without error messages.
> > > > However, later creating a Akonadi::CollectionFetchJob still causes
> > > > some
> > > > of the same error messages - less of them, but still some:
> > > > 
> > > > akonadi_agent_launcher: cannot connect to X server
> > > > ProcessControl: Application '/usr/bin/akonadi_agent_launcher' returned
> > > > with exit code 1 (Unknown error)
> > > > akonadi_agent_launcher: cannot connect to X server
> > > > ProcessControl: Application '/usr/bin/akonadi_agent_launcher' returned
> > > > with exit code 1 (Unknown error)
> > > > akonadi_agent_launcher: cannot connect to X server
> > > > ProcessControl: Application '/usr/bin/akonadi_agent_launcher' returned
> > > > with exit code 1 (Unknown error)
> > > > akonadi_agent_launcher: cannot connect to X server
> > > > ProcessControl: Application '/usr/bin/akonadi_agent_launcher' returned
> > > > with exit code 1 (Unknown error)
> > > > "/usr/bin/akonadi_agent_launcher" crashed too often and will not be
> > > > restarted!
> > > > 
> > > > It is /usr/bin/akonadi_control which
> > > > forks/execs /usr/bin/akonadi_agent_launcher (verified with strace) and
> > > > it has AKONADI_DISABLE_AGENT_AUTOSTART set.
> > > > 
> > > > Any idea how to suppress that?
> > > 
> > > In addition, my own process
> > > launches /usr/share/kde4/apps/akonadi/firstrun/defaultcalendar,
> > > /usr/share/kde4/apps/akonadi/firstrun/defaultnotebook and
> > > /usr/bin/kres-migrator.
> > 
> > The agent can be started by the firstrun migration. Create
> > akonadi-firstrunrc in $KDEHOME/share/config/
> > 
> > [ProcessedDefaults]
> > defaultaddressbook=done
> > defaultcalendar=done
> > defaultnotebook=done
> 
> KDEHOME wasn't set in my environment. strace told me that the process
> was looking for the file in ~/.kde/share/config, so I used that. It
> works, thanks.

Hi,

$KDEHOME is by default $HOME/.kde or  $HOME/.kde4, depends on distributions, 
so you got it right :-) But it's dangerous for testing, as it means Akonadi 
works on top of your data.

> Now nightly testing with KDE has one last issue: when I run tests in
> parallel under the same user ID with multiple different D-Bus sessions
> and different homes (set via env variables), MySQL gets started multiple
> times (as it should be), but then I get errors about "MySQL server has
> gone away". I suspect the different instances of MySQL still conflict.

Sorry, I did not understand from your previous emails that you want to use 
this for testing. We already have an infrastructure for running tests that 
require Akonadi server. 

If you install kdepimlibs, you will automatically get and akonaditest utility 
and akonadi_knut_resource installed.

The main advantage of akonaditest is that each test is ran in separated, clean 
environment set up for each test into /tmp.

You can use akonaditest like this:

akonaditest -c /path/to/a/config/file /path/to/unittest/binary

For the config file you can use kdepimlibs/akonadi/tests/unittestenv/config-
sqlite-db.xml.  Content of kdehome directory will be copied to the test 
environment as $KDEHOME (so something like /tmp/akonadi-
test.randomstring/kdehome/.kde/).

The <agent> entry defines which Akonadi agents to start. By default no agents 
at all are started. The Akonadi Knut Resource specified in the config file is 
a special resource for testing. When started, it populed the Akonadi database 
by data from kdehome/share/testdata-res1.xml. This way you can push initial 
data into Akonadi and observe whether they are correctly fetched and processed 
by your code. Look for example on itemfetchtest.cpp in 
kdepimlibs/akonadi/tests.

> Would it be easier to use sqlite as backend? Which one is considered
> more stable these days?

SQLite is indeed preferred for unit-tests as it does not have problems running 
multiple instances at the same time and is faster to setup, start  and 
shutdown than MySQL or PSQL, which makes the tests faster in overall.

It has always been pretty stable, it's only problem is that it lacks support 
for concurrent transaction, so all transaction are serialized, which slows 
down everything. However for a unit-tests this is OK, since the number of 
operations and concurrency is very limited.

> I tried with sqlite. Now SyncEvolution randomly hangs, with gdb showing
> that it is stuck in an Akonadi Job::exec() call:
> 
> #0  0x00007f0233f5b95d in poll () at ../sysdeps/unix/syscall-template.S:81
> #1  0x00007f0234a89194 in g_main_context_poll (priority=2147483647, n_fds=3,
> fds=0x2188090, timeout=-1, context=0x215dcf0) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3995 #2  g_main_context_iterate
> (context=context at entry=0x215dcf0, block=block at entry=1,
> dispatch=dispatch at entry=1, self=<optimized out>) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3696 #3  0x00007f0234a8929c in
> g_main_context_iteration (context=0x215dcf0, may_block=1) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3762
> #4  0x00007f02375b5615 in
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> #5  0x00007f0237586f9f in
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> #6  0x00007f0237587295 in
> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/x86_64-linux-gnu/libQtCore.so.4
> #7  0x00007f0237c9e683 in KJob::exec() () from /usr/lib/libkdecore.so.5
> #8  0x00000000006321ad in SyncEvo::AkonadiSyncSource::getDatabases
> (this=0x21f7670) at
> /data/runtests/work/sources/syncevolution/src/backends/akonadi/akonadisyncs
> ource.cpp:139 #9  0x00000000006e2bdc in SyncEvo::Cmdline::run
> (this=this at entry=0x7fff4247aa20) at
> /data/runtests/work/sources/syncevolution/src/syncevo/Cmdline.cpp:1257 #10
> 0x00000000005d8bd6 in SyncEvo::main (argc=<optimized out>, argv=<optimized
> out>) at
> /data/runtests/work/sources/syncevolution/src/syncevolution.cpp:531

Could you please get full backtrace from akonadiserver process when this 
happens? Looks like something gets stuck on the server and the Job is just 
waiting for response endlessly.

Thanks,
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/20140317/87a01ae4/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/