Hi gang,

I got hold of a nice new (but somewhat dated) Dell PowerEdge tower and put FreeBSD onto it (which so happens to be my favorite Unix-like environment). Because I had plenty of room and resources I decided to go against my regular policy and put Xorg and KDE4 onto it as well (usually I keep my servers "X free" (some pun intended ).

SO far, so good, almost everything pretty much works, but I can't get Akonadi to work. I've set up a PostgreSQL backend and it has no problems connecting to the database, but keeps complaining that it isn't registered with DBUS:

Code: Select all

Test 4:  ERROR
--------
Akonadi control process not registered at D-Bus.
Details: The Akonadi control process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup.

Test 5:  ERROR
--------
Akonadi server process not registered at D-Bus.
Details: The Akonadi server process is not registered at D-Bus which typically means it was not started or encountered a fatal error during startup.


Well, DBus is started (together with hald) because otherwise I wouldn't be able to even type this on my server

Code: Select all

root@omicron:/home/peter # service dbus status
dbus is running as pid 68292.
root@omicron:/home/peter # service hald status
hald is running as pid 68327.


Now, I'm by far an expert on DBus because I seldomly use it but from what I can tell Akonadi should be registered. I noticed that it placed a service entry in /usr/local/share/dbus-1/services called org.freedesktop.Akonadi.Control.service. From that file I obtained the name org.freedesktop.Akonadi.Control. So looking deeper into DBus I came across dbus-monitor(1) and from there I managed to do this:

Code: Select all

$ dbus-monitor "type='signal',sender='org.freedesktop.Akonadi.Control',interface='org.freedesktop.Akonadi.Control'"
signal time=1509957321.904208 sender=org.freedesktop.DBus -> destination=:1.164 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.164"
signal time=1509957321.904483 sender=org.freedesktop.DBus -> destination=:1.164 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.164"


As said I'm no expert but it looks to me as if DBus does recognize this specific Akonadi part. Note that org.freedesktop.Akonadi.Server has the same positive results. Also noteworthy: this was obviously done using the same user account which started the X environment (done through startx with having added 'startkde' in ~/.xinitrc (without the quotes obviously)).

So if I try to enter some bogus information then I notice that the program gives me a very obvious error message:

Code: Select all

$ dbus-monitor "type='signal',sender='shelluser',interface='shelluser'"
dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.MatchRuleInvalid: "Sender name 'shelluser' is invalid
". Falling back to eavesdropping.
Failed to setup match "eavesdrop=true,type='signal',sender='shelluser',interface='shelluser'": Sender name 'shelluser' is invalid


Ergo my conclusion: Akonadi is being serviced through DBus since it recognizes it.

But that also brings me to my problem: what could cause Akonadi to claim that it's not registered with DBus while it seems that it is?

Can't help be convinced that it must be something small and silly which I'm not seeing but... yah..

Hope someone can shed a little light on this, thanks in advance for any hints or tips!

Kind regards, Peter

And solved!

This was tricky but doable. SO... let me elaborate and hopefully this can also help out someone else in the future.

As mentioned above I had sorted out my PostgreSQL storage, this was actually my preference. And this is what I was looking at when I ran the "Akonadi Configuration" panel (by using the search option in the menu):


w00t, deskutils/puush to the rescue!

As I figured in my previous message I overlooked something obvious: the DBus error you see above is actually a little bit misleading (or so I think!). See: it's not so much that Akonadi isn't registered with DBus but more so that the test environment somehow can't verify this. I don't know why, but my theory is because the server wasn't running. Now, that causes a little bit of a chicken & egg kind of problem, but even so.. that's my theory so far.

After more studying I noticed akonadictl which mentioned that the program could be used to start and stop the server. Well, on the commandline I would probably at least get some useful output (or so I hoped) and guess what? I did:

Code: Select all

executable: "/usr/local/bin/pg_ctl"
arguments: ("start", "-w", "--timeout=10", "--pgdata=/home/peter/.local/share/akonadi/db_data", "-o "-k/tmp" -h ''")
stdout: "waiting for server to start....FATAL:  could not open lock file "/tmp/.s.PGSQL.5432.lock": Permission denied
 stopped waiting
"
stderr: "pg_ctl: could not start server
Examine the log output.
"
exit code: 1
process error: "Process operation timed out"


More strange error messages (for me) because didn't it tell me a moment ago that it could find and utilize the postgres backend? So what if my environment was too tightly set up? It's a theory I have, but it's not unusual to point pg_ctl(1) to the actual PostgreSQL data directory. Heck, this is even how they sort this out on Windows. Yah, but on my system that is most definitely not going to work:

Code: Select all

omicron:/home/peter/temp/kde $ ls ~pgsql/data/pg_hba.conf
ls: /usr/local/pgsql/data/pg_hba.conf: Permission denied
omicron:/home/peter/temp/kde $ ls -l ~pgsql
total 2
drwx------  19 pgsql  pgsql  26 Nov  6 14:07 data


Trust me: my server is working just fine, no problems at all:

Code: Select all

omicron:/home/peter/temp/kde $ psql -c \\l | grep akonadi
 akonadi   | akonadi   | UTF8     | C       | C     |


So... if PostgreSQL isn't going to work, then I figured I should use my fallback. Just for this reason I had build Akonadi with 2 backends: postgres and sqlite3. And that did the trick! After changing the storage to SQLite (using the same method as described above) I tried to use 'akonadictl start' and wham!

Well, in the mean time puush died on me, but I just discovered something even better: graphics/kipi-plugins-kde4! I just revised an old Gallery2 environment this afternoon and still had to upload dozens of files into that to complete a downloaded web comic collection (20 years of comics! ). I guess it's needless to say but KDE to the rescue as usual!

I did study the file ~/.config/akonadi/akonadiserverrc and for a brief moment I hoped that StartServer might prevent Akonadi from trying to fire up postgres and just start using it, but that was false hope unfortunately. Even so: nothing wrong with a nice SQlite3 backend:


One fully working Akonadi backend server!

And there you have it... So:

• Try using akonadictl to start the server and check your output (worst case scenario try this: akonadictl start 2>&1 > ctl.log)
• Always check the log(s) for whatever backend you configured, sometimes (not always!) they can also shed some light on this.
• When in doubt drop back to SQLite and optionally work your way up from there again.

Hope this can be useful for someone.