[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Akonadi not starting



On Tuesday 14 April 2009, jedd wrote:
>  Hi Kevin,
>
>  On that URL previously posted, there was a comment regarding the
>  problem (as yet unresolved) of handling mail systems that used a
>  combination of mbox and maildir. I gather maildir is the preferred way
>  these days - and on my desktop computer I used to use this all the
>  time as the default.  mbox, though, has advantages when dealing with
>  mailing list folders containing thousands of messages - mostly when it
>  comes to copying those (think rsync).  The delay is not the size of
>  the content - it's a relatively trivial - it's the pain of rsync
>  having to index several thousand files and then compare them each
>  individually.  Hence .. my hybrid arrangements.  And I doubt I'm the
>  only person left running mbox & maildir concurrently.

Ah.
That comment is referring to KMail's local directory tree, where it mixes 
maildir and mbox as mail folders.
There is no support yet to map this directly into a single Akonadi resource, 
however it is already possible to access maildir (recursively IIRC) and mbox 
(coming with 4.3) through separate resources.

>  Anyhoo ...
>
> > I think it is 100MB (configurable) per database daemon.
> > Transaction logs of the InnoDB backend of mysql or something like
> > that.
>
>  Yes .. I get that.  I run a local mysql database server already,and
>  I think this stuff they're talking about is the shared ibdata1 file
>  yeah?  If so, then it shouldn't be an extra 100+MB hit for very
>  additional user.  If it's 100MB of 'wrapper' stuff *within* the DB,
>  for every *user*, then we're up for a major hit.   I strongly suspect
>  it's the former, however.

It mostly a per daemon overhead, not per database. Something used internally 
by the InnoDB backend of MySQL, can't remember the details.

>  I fought with Akonadi for a little while -- too many other bugs from
>  KDE 4 were being fought for the first few days -- and then set
>  up a DB manually in mysql, and re-configured the akonadi config
>  to suit.  It seems to work, but I notice in the Akonadi console
>  that two of my apps aren't using Akonadi yet .. though the
>  distinction, for me, of what that actually means is still a little
>  fuzzy.  By which I mean, because Akonadi is a pipe, rather
>  than a store, I'm not sure if I need to change contacts/addressbook
>  and notes (etc) or if that'll just happen over time with new releases.

I am not aware of any way Akonadiconsole could display which apps are not 
using Akonadi.
It is basically a developer tool interface for the resource/agent 
configuration usually available through KDE's system settings.

Since you started with an empty .kde dir you probably haven't got any 
resources. Or maybe one file resource for vcard and ical?

Someone migrating from a previous KDE setup should get one Akonadi resource 
per KDE kresource they had, e.g. one vcard resource for every file based 
addressbook they had.

Client side migration, i.e. using KResource plugins which access data in 
Akonadi, have been disabled for the 4.2 series since that part has proven to 
be more difficult than anticipated.
It is, as an option, available through manual intervention though.

>  I'm unsure whether to just mention what I did here (in case it's
>  of use to other travellers) or to point at my web site where I'm
>  annotating various 4.2.2 woes (and fixes).

Wouldn't hurt to let others know about the web site IMHO.

>  Akonadi's config is not located under .kde - which is an interesting
>  call .. but I can see the reasoning.

Well, it is not a KDE service, so putting it under .kde would not make much 
sense.
.config or rather $XDG_CONFIG_HOME (defaulting to $HOME/.config) is the 
standard location pro configs as proposed by the freedesktop.org base 
directory specification.

>  For future reference - if you modify this file:
>  ~/.config/akonadi/akonadiserverrc
>
>  And my system is set thus:
> [QMYSQL]
> Name=akonadi_jedd
> User=akonadi_jedd
> Password=secret
> Options=
> ServerPath=/usr/sbin/mysqld
> StartServer=false
> Host=localhost
>
>  I used that database name because I'll have multiple users attaching
>  to the same database server.  I used that user name for obvious
>  reasons.  I removed Options because it seemed to be confusing the
>  restart of the service.  I have StartServer set to false because I'm
>  using a real mysqld, not wanting Akonadi to start its own.  I set
>  host to point to my mysql host, of course.

Yes, this is how it is supposed to be for a shared and adminstrated mysql 
instance.
I mentioned StartServer in my other reply because the mail I was replying to 
had that set to false despite pointing the Qt SQL plugin to a local socket.

I am not even sure you need the ServerPath variable, I think it is only needed 
when StartServer is true.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: