When I try to synchronize my computers with syncevo-http-server (which starts syncevo-dbus-server), it fails with "Akonadi is not running. It can be started with 'akonadictl start'." Akonadi however is running and "syncevolution --print-databases" finds the akonadi collections. The following simple test program prints "Running": #include <Akonadi/ServerManager> #include <iostream> int main() { if (Akonadi::ServerManager::isRunning()) std::cout << "Running" << std::endl; else std::cout << "Not running" << std::endl; return 0; }
(In reply to comment #0) > When I try to synchronize my computers with syncevo-http-server (which > starts syncevo-dbus-server), it fails with "Akonadi is not running. It can > be started with 'akonadictl start'." > > Akonadi however is running and "syncevolution --print-databases" finds the > akonadi collections. > > The following simple test program prints "Running": > > #include <Akonadi/ServerManager> > #include <iostream> > > int main() > { > if (Akonadi::ServerManager::isRunning()) > std::cout << "Running" << std::endl; > else > std::cout << "Not running" << std::endl; > return 0; > } SyncEvolution should already call Akonadi::ServerManager::isRunning() in syncevo-dbus-server each time it tries to use an Akonadi source. You can verify that with: gdb -p `pidof syncevo-dbus-server` # while syncevo-dbus-server is still running b SyncEvo::AkonadiSyncSource::start catch throw cont This should break in SyncEvo::AkonadiSyncSource::start. Enter "finish". Instead of returning from the call, it show break on the exception that you see ("Akonadi is not running. It can be started with 'akonadictl start'."). Could it be that Akonadi was not running yet when syncevo-dbus-server was started? Perhaps Akonadi::ServerManager::isRunning() only checks once and then does not notice when Akonadi gets started later on. Just an idea. Can you run the check with gdb above and give more information about your Linux distro? Which version of SyncEvolution?
(In reply to comment #0) > When I try to synchronize my computers with syncevo-http-server (which > starts syncevo-dbus-server), it fails with "Akonadi is not running. It can > be started with 'akonadictl start'." Wait, I forgot to ask about this: is syncevo-dbus-server running in the same D-Bus session as Akonadi? In other words, how exactly do you run syncevo-http-server?
(In reply to comment #1) > (In reply to comment #0) > > When I try to synchronize my computers with syncevo-http-server (which > > starts syncevo-dbus-server), it fails with "Akonadi is not running. It can > > be started with 'akonadictl start'." > > > > Akonadi however is running and "syncevolution --print-databases" finds the > > akonadi collections. > > > > The following simple test program prints "Running": > > > > #include <Akonadi/ServerManager> > > #include <iostream> > > > > int main() > > { > > if (Akonadi::ServerManager::isRunning()) > > std::cout << "Running" << std::endl; > > else > > std::cout << "Not running" << std::endl; > > return 0; > > } > > SyncEvolution should already call Akonadi::ServerManager::isRunning() in > syncevo-dbus-server each time it tries to use an Akonadi source. You can > verify that with: > > gdb -p `pidof syncevo-dbus-server` # while syncevo-dbus-server is still > running > b SyncEvo::AkonadiSyncSource::start > catch throw > cont > > This should break in SyncEvo::AkonadiSyncSource::start. ... unless you already configured the sync successfully or do that via the command line. If you already have a config and only the actual syncing fails, then Akonadi gets used by syncevo-dbus-helper again, just as in --print-databases. In that case it is more likely a problem with your syncevo-http-server setup (see the other comment).
> SyncEvolution should already call Akonadi::ServerManager::isRunning() in > syncevo-dbus-server each time it tries to use an Akonadi source. Yes, I have seen that. Hence I tried if the call succeeds in my test program. > You can verify that with: > > gdb -p `pidof syncevo-dbus-server` # while syncevo-dbus-server is still > running > b SyncEvo::AkonadiSyncSource::start > catch throw > cont > > This should break in SyncEvo::AkonadiSyncSource::start. Enter "finish". > Instead of returning from the call, it show break on the exception that you > see ("Akonadi is not running. It can be started with 'akonadictl start'."). > > Could it be that Akonadi was not running yet when syncevo-dbus-server was > started? Perhaps Akonadi::ServerManager::isRunning() only checks once and > then does not notice when Akonadi gets started later on. Just an idea. No, it was running. I checked several times. > Can you run the check with gdb above and give more information about your > Linux distro? Which version of SyncEvolution? I use Exherbo as my linux distribution. I have KDE 4.12.2 and Akonadi (server) 1.11.0. The dbus version is 1.8.0. The problem occurs with SyncEvolution 1.4. I will upload the output of gdb. The exception it caught occured a few seconds _after_ the output "Akonadi is not running. It can be started with 'akonadictl start'.". > Wait, I forgot to ask about this: is syncevo-dbus-server running in the same > D-Bus session as Akonadi? > > In other words, how exactly do you run syncevo-http-server? I think it is. I started it by entering "syncevo-http-server http://localhost:9000" in a console that ran in the local user session. > ... unless you already configured the sync successfully or do that via the > command line. If you already have a config and only the actual syncing fails, > then Akonadi gets used by syncevo-dbus-helper again, just as in --print- > databases. In that case it is more likely a problem with your syncevo-http- > server setup (see the other comment). Yes, I already have a config that used to work with SyncEvolution 1.3 (But I did not use it for about a month).
Created attachment 94983 [details] Output from gdb
(In reply to comment #4) > > You can verify that with: > > > > gdb -p `pidof syncevo-dbus-server` # while syncevo-dbus-server is still > > running > > b SyncEvo::AkonadiSyncSource::start > > catch throw > > cont > > > > This should break in SyncEvo::AkonadiSyncSource::start. Enter "finish". > > Instead of returning from the call, it show break on the exception that you > > see ("Akonadi is not running. It can be started with 'akonadictl start'."). > > > > Could it be that Akonadi was not running yet when syncevo-dbus-server was > > started? Perhaps Akonadi::ServerManager::isRunning() only checks once and > > then does not notice when Akonadi gets started later on. Just an idea. > > No, it was running. I checked several times. As I speculated in my later comment, it's not syncevo-dbus-server which checks for Akonadi during the sync, and therefore the exception in it is related to something else (probably shutting down the sync). > > Can you run the check with gdb above and give more information about your > > Linux distro? Which version of SyncEvolution? > > I use Exherbo as my linux distribution. I have KDE 4.12.2 and Akonadi > (server) 1.11.0. The dbus version is 1.8.0. The problem occurs with > SyncEvolution 1.4. How was SyncEvolution compiled? gdb doesn't seem to find debug information for /usr/lib64/../lib64/libsyncevolution.so.0, which would be useful for further analysis of the problem. Was KDE support enabled while building SyncEvolution? Perhaps Akonadi depends on a KApplication instance, which is what KDEInitMainSlot in the kdeplatform.so creates. Does Akonadi access work for you at all or is it only failing during syncing via HTTP? The simplest possible test is: SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases backend=kde-contacts This does not fork any processes, so gdb can be run on it more easily: SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --print-databases backend=kde-contacts When I run dbus-monitor in parallel, I see that it looks for some well-known Akonadi names. Below is the failure when Akonadi is not running. Note that the log starts with claiming and releasing a name for the SyncEvolution instance; that's part of the KApplication startup, followed by freeing the name again in KDEInitMainSlot. dbus-monitor doesn't seem to dump the response to the NameHasOwner method call, neither when it succeeds nor when it fails. What does you log look like? signal sender=org.freedesktop.DBus -> dest=(null destination) serial=29 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.23" string "" string ":1.23" method call sender=:1.23 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=org.freedesktop.DBus -> dest=(null destination) serial=30 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.24" string "" string ":1.24" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=org.freedesktop.DBus -> dest=(null destination) serial=31 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.syncevolution.syncevolution-7239" string "" string ":1.24" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.syncevolution.syncevolution-7239" uint32 4 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=32 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.syncevolution.syncevolution-7239" string ":1.24" string "" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName string "org.syncevolution.syncevolution-7239" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi.Control" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi" method call sender=:1.24 -> dest=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi.Control.lock" [ERROR 00:00:00] Akonadi is not running. It can be started with 'akonadictl start'. signal sender=org.freedesktop.DBus -> dest=(null destination) serial=33 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.24" string ":1.24" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=34 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.23" string ":1.23" string ""
> > > Can you run the check with gdb above and give more information about your > > > Linux distro? Which version of SyncEvolution? > > > > I use Exherbo as my linux distribution. I have KDE 4.12.2 and Akonadi > > (server) 1.11.0. The dbus version is 1.8.0. The problem occurs with > > SyncEvolution 1.4. > > How was SyncEvolution compiled? gdb doesn't seem to find debug information > for /usr/lib64/../lib64/libsyncevolution.so.0, which would be useful for > further analysis of the problem. > > Was KDE support enabled while building SyncEvolution? Perhaps Akonadi > depends on a KApplication instance, which is what KDEInitMainSlot in the > kdeplatform.so creates. I used the following configure-line: ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --docdir=/usr/share/doc/syncevolution-1.4 --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --enable-release-mode --enable-libsoup --enable-core --enable-doc --enable-dbus-service --disable-dbus-service-pim --disable-dlt --enable-notify --disable-gui --disable-gnome-bluetooth-panel-plugin --disable-activesync --disable-sqlite --disable-addressbook --disable-file --disable-kcalextended --disable-maemocal --disable-qtcontacts --disable-dav --disable-xmlrpc --enable-akonadi --enable-bluetooth --disable-ecal --disable-ebook --disable-gnome-keyring --enable-kwallet If "KDE support" is support for kwallet then it was enabled. I have recompiled syncevolution with debug information. I will upload the backtrace. > Does Akonadi access work for you at all or is it only failing during syncing > via HTTP? > > The simplest possible test is: > > SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases > backend=kde-contacts This works and lists all my akonadi collections for my contacts. > This does not fork any processes, so gdb can be run on it more easily: > > SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no --print-databases > backend=kde-contacts I think it does not make sense to debug this since it works for me. > When I run dbus-monitor in parallel, I see that it looks for some well-known > Akonadi names. Below is the failure when Akonadi is not running. Note that > the log starts with claiming and releasing a name for the SyncEvolution > instance; that's part of the KApplication startup, followed by freeing the > name again in KDEInitMainSlot. dbus-monitor doesn't seem to dump the > response to the NameHasOwner method call, neither when it succeeds nor when > it fails. > > What does you log look like? My log for the "--print-databases" case is quite long, it begins with: signal sender=org.freedesktop.DBus -> dest=(null destination) serial=416 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.242" string "" string ":1.242" method call sender=:1.242 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=org.freedesktop.DBus -> dest=(null destination) serial=417 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.243" string "" string ":1.243" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=org.freedesktop.DBus -> dest=(null destination) serial=418 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.syncevolution.syncevolution-4402" string "" string ":1.243" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.syncevolution.syncevolution-4402" uint32 4 signal sender=org.freedesktop.DBus -> dest=(null destination) serial=419 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.syncevolution.syncevolution-4402" string ":1.243" string "" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=ReleaseName string "org.syncevolution.syncevolution-4402" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi.upgrading" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi.Control" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameHasOwner string "org.freedesktop.Akonadi" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.freedesktop.Akonadi.Control" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.Akonadi.Control'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentTypeAdded'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner string "org.freedesktop.Akonadi.Control" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=11 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentTypeRemoved'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=12 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceAdded'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=13 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceRemoved'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=14 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceStatusChanged'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=15 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceProgressChanged'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=16 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceNameChanged'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=17 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceWarning'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=18 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceError'" method call sender=:1.243 -> dest=org.freedesktop.DBus serial=19 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',sender='org.freedesktop.Akonadi.Control',path='/AgentManager',interface='org.freedesktop.Akonadi.AgentManager',member='agentInstanceOnlineChanged'" method call sender=:1.243 -> dest=org.freedesktop.Akonadi.Control serial=20 path=/AgentManager; interface=org.freedesktop.Akonadi.AgentManager; member=agentTypes After that it lists all the akonadi agents. I will upload the output of dbus-monitor for syncevo-http-server.
Created attachment 95186 [details] Output from gdb with debug information
Created attachment 95187 [details] dbus-monitor output for syncevo-http-server
I'm having the same issue. "syncevolution Steffis-Handy" (a bluetooth profile to my Nokia e71) fails with "[ERROR] Akonadi is not running. It can be started with 'akonadictl start'." but "akonadictl start" gives "Akonadi is already running." Restarting akonadi doesn't help. I'm running Debian unstable with KDE 4.13 from experimental, Akonadi 1.11.0 and syncevolution 1.4-1 from Debian. Please tell me what additional information I can supply.
I can reproduce the problem. I'm working on it now.
The problem occurs when syncing executes the source initialization in a background thread. Akonadi::ServerManager::isRunning() then returns false despite Akonadi running. This initialization in a thread was introduced to avoid timeout issues with slow sources: * engine: prevent timeouts in HTTP server mode HTTP SyncML clients give up after a certain timeout (SyncEvolution after RetryDuration = 5 minutes by default, Nokia e51 after 15 minutes) when the server fails to respond. This can happen with SyncEvolution as server when it uses a slow storage with many items, for example via WebDAV. In the case of slow session startup, multithreading is now used to run the storage initializing in parallel to sending regular "keep-alive" SyncML replies to the client. By default, these replies are sent every 2 minutes. This can be configured with another extensions of the SyncMLVersion property: SyncMLVersion = REQUESTMAXTIME=5m Other modes do not use multithreading by default, but it can be enabled by setting REQUESTMAXTIME explicitly. It can be disabled by setting the time to zero. The new feature depends on a libsynthesis with multithreading enabled and glib >= 2.32.0, which is necessary to make SyncEvolution itself thread-safe. With an older glib, multithreading is disabled, but can be enabled as a stop-gap measure by setting REQUESTMAXTIME explicitly. I checked, setting SyncMLVersion=REQUESTMAXTIME=0m in the sync config involving the Akonadi sources works around the problem for me. I'll check with the KDE devs to find out why Akonadi::ServerManager::isRunning() fails in this scenario.
Darn, "if (!UID)" is not valid in Synthesis scripts because it always evaluates to "true". This here is the correct line: if (UID == EMPTY) { UID = newuid(); } Niels, just for the sake of completeness, can you try that?
(In reply to comment #13) > Darn, "if (!UID)" is not valid in Synthesis scripts because it always > evaluates to "true". This here is the correct line: > > if (UID == EMPTY) { UID = newuid(); } > > Niels, just for the sake of completeness, can you try that? Did you mean to post this as a comment to bug #74342?
(In reply to comment #14) > (In reply to comment #13) > > Darn, "if (!UID)" is not valid in Synthesis scripts because it always > > evaluates to "true". This here is the correct line: > > > > if (UID == EMPTY) { UID = newuid(); } > > > > Niels, just for the sake of completeness, can you try that? > > Did you mean to post this as a comment to bug #74342? Indeed, I picked the wrong browser tab. Literally too many issues open in parallel ;-} I'll repost.
While I'm here, I have a solution for the Akonadi issue in HTTP server mode. I also enhanced testing to cover Akonadi again (was disabled temporarily because the setup of Akonadi was no longer stable after parallelizing testing).
Fix is in master and SyncEvolution 1.4.1 (currently available as individual download and from the "unstable" repo on syncevolution.org).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.