4:23 p.m.
Hello world,
this is my first post to this list. Recently I set up funambol and
syncevolution with caldav/carddav on my little arm box. The first sync
worked, however since then upon running syncevolution leads to aborted
syncs and the attached log.
From reading the logfile it seems that syncevolution decides that it
is better to abort but I cannot see the reason for that.
Now I do not see a spot where the investigation should be started:
This might be an issue with the data itself, syncevolution, funambol
or even a performance issue since syncevolution, funambol and the
webdav (owncloud) are running on the same hardware.
What would be a good place to start?
Regards
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
6:17 a.m.
On Wed, 2013-01-23 at 00:23 +0100, Christof Schulze wrote:
Hello world,
this is my first post to this list. Recently I set up funambol and
syncevolution with caldav/carddav on my little arm box. The first sync
worked, however since then upon running syncevolution leads to aborted
syncs and the attached log.
From reading the logfile it seems that syncevolution decides that it
is better to abort but I cannot see the reason for that.
That should also have been the error message on stdout:
Doing a slow synchronization may lead to duplicated
items or lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status funambol addressbook
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client] funambol
addressbook
So to fix it temporarily, do a refresh sync as suggested. Note that
"from-client" will take the data from the WebDAV side.
The main question is why the slow sync was necessary.
In this case, the Funambol server decides to do a slow sync:
[2013-01-22 21:01:12.301] Alerted (code=201) for two-way Slow
Sync
It's impossible to say why it does that. One would have to check the
client and server side logs of the previous sync to figure out whether
it really finished cleanly on both sides.
Now I do not see a spot where the investigation should be started:
This might be an issue with the data itself, syncevolution, funambol
or even a performance issue since syncevolution, funambol and the
webdav (owncloud) are running on the same hardware.
May I ask what you need Funambol for? Perhaps SyncEvolution could do it?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
6:31 p.m.
Hi,
That should also have been the error message on stdout:
Doing a slow synchronization may lead to duplicated
items or lost data when the server merges items incorrectly.
Choosing a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the following
sync modes to recover from this problem:
slow, refresh-from-server, refresh-from-client
Analyzing the current state:
syncevolution --status funambol addressbook
Running with one of the three modes:
syncevolution --sync [slow|refresh-from-server|refresh-from-client]
funambol addressbook
this was indeed visible on stdout.
So to fix it temporarily, do a refresh sync as suggested. Note that
"from-client" will take the data from the WebDAV side.
Refreshing from
server works, however upon the next regular run, again
syncevolution reports an unexpected slow sync and the story starts
over again.
It's impossible to say why it does that. One would have to check
the
client and server side logs of the previous sync to figure out
whether it really finished cleanly on both sides.
Funambol shows me these:
[2013-01-24 00:51:05,080] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Handling incoming request
[2013-01-24 00:51:05,244] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Request URL:
https://kdserv.dyndns.org:8443/funambol/ds
[2013-01-24 00:51:05,245] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Requested sessionId:
419E650606328E12C6751F0D2E1B1291
[2013-01-24 00:55:51,437] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Request processed.
[2013-01-24 00:59:54,248] [funambol.transport.http] [INFO]
[08500EFCEAA6AE7A528C7BBB9AEC1276] [192.168.142.54] [] [] [] Closing session
08500EFCEAA6AE7A528C7BBB9AEC1276
[2013-01-24 01:06:22,147] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Closing session
419E650606328E12C6751F0D2E1B1291
[2013-01-24 01:06:22,213] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] moving to state: STATE_ERROR
[Session aborted with status code: SESSION_EXPIRED]
[2013-01-24 01:06:22,236] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] moving to state: STATE_ENDED
[2013-01-24 01:06:22,237] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Synchronization completed with
error(s)
I found a couple of remarks from 2010 on the web saying there is a bug
in the oxtender but at this point I am probably better off, turning to a
funambol mailinglist.
> Now I do not see a spot where the investigation should be
started:
> This might be an issue with the data itself, syncevolution, funambol
> or even a performance issue since syncevolution, funambol and the
> webdav (owncloud) are running on the same hardware.
May I ask what you need Funambol for? Perhaps Syncevolution could do
it?
Funambol is used because I want to be able to synchronize my nokia e51
phone to my server at any time from anywhere.
However, and that is what I use syncevolution for, I would also like
my calendar from my nokie e51 to show up in a calendar in my owncloud
instance - hence the syncml-webdav-sync.
If that is possible with less hassle (at the moment it does not work
due to this kind of synchronisation issues) without using funambol -
perfect! What should I read to find out what to set up?
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
7:31 p.m.
On Thu, 2013-01-24 at 02:31 +0100, Christof Schulze wrote:
I found a couple of remarks from 2010 on the web saying there is a
bug
in the oxtender but at this point I am probably better off, turning to a
funambol mailinglist.
It's indeed hard to tell why the server thinks that the session is not
done yet when the client has already quit.
> > Now I do not see a spot where the investigation should be
started:
> > This might be an issue with the data itself, syncevolution, funambol
> > or even a performance issue since syncevolution, funambol and the
> > webdav (owncloud) are running on the same hardware.
> May I ask what you need Funambol for? Perhaps Syncevolution could do
> it?
Funambol is used because I want to be able to synchronize my nokia e51
phone to my server at any time from anywhere.
However, and that is what I use syncevolution for, I would also like
my calendar from my nokie e51 to show up in a calendar in my owncloud
instance - hence the syncml-webdav-sync.
If that is possible with less hassle (at the moment it does not work
due to this kind of synchronisation issues) without using funambol -
perfect! What should I read to find out what to set up?
A first starting pointer is the howto for using SyncEvolution itself as
a SyncML server:
https://syncevolution.org/wiki/http-server-howto
The difference is that you don't want to use a local file database in
that SyncML server. Instead you want it to act as a bridge for CalDAV.
That's possible: instead of configuring a SyncML client of the Funambol
server (which you have already working), configure the SyncML server
side for the e51 inside the context where the local database is the
CalDAV source and thus let the e51 talk to Owncloud directly, without
mirroring.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:31 p.m.
Hello,
the funambol configuration works now. All I did was to manuall start
the synchronisation for a couple of times while limiting the sync to
the addressbook and then again limiting it to the calendar.
However funambol is a memory hog (separate database, tomcat instance,
java application) hence I would like to replace it with something more
lightweight.
After having received feedback about using syncevo-http-server, I
tried to set things up according to https://syncevolution.org/wiki/http-
server-howto
When I try to synchronize just the addressbook datasource from the
phone the phone states that the server Url is invalid and the server
prints out the following error:
[ERROR] twisted: Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in
dataReceived
finishCallback(data[contentLength:])
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in
_finishRequestBody
self.allContentReceived()
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in
allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in
requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in
process
self.render(resrc)
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in
render
body = resrc.render(self)
File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216,
in render
return m(request)
File "/usr/bin/syncevo-http-server", line 302, in render_POST
urlparse.urljoin(self.url.geturl(), request.path))
File "/usr/bin/syncevo-http-server", line 218, in start
'')
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in
__call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: No
such interface `org.syncevolution.Server' on object at path
/org/syncevolution/Server
[DEBUG] twisted: 213.211.219.200 - - [05/Feb/2013:20:22:52 +0000] "POST /sync
HTTP/1.1" 500 9391 "-" "Nokia SyncML HTTP Client"
[DEBUG] syncevo-http: done with request in session None, error None
[DEBUG] sync: /org/syncevolution/Server: http presence signal funambol,no
transport,https://kdserv.dyndns.org:8443/funambol/ds
[DEBUG] sync: /org/syncevolution/Server: http presence signal target-config,no
transport,http://yourserver:port
[WARNING] sync: /org/syncevolution/Server: libnotify: Failed to connect to
proxy
[DEBUG] sync: /org/syncevolution/Server: auto sync: updating info about config
christofphon
[DEBUG] sync: /org/syncevolution/Server: auto sync: christofphon: auto sync
'0', no Bluetooth, no HTTP, 1800 seconds repeat interval, 300 seconds online
delay
[DEBUG] sync: /org/syncevolution/Server: auto sync: reschedule, initConfig()
for christofphon
[DEBUG] sync: /org/syncevolution/Server: auto sync: nothing to do
[DEBUG] sync: /org/syncevolution/Server: auto sync: updating info about config
funambol
[DEBUG] sync: /org/syncevolution/Server: auto sync: funambol: auto sync '0',
no Bluetooth, no HTTP, 1800 seconds repeat interval, 300 seconds online delay
[DEBUG] sync: /org/syncevolution/Server: auto sync: reschedule, initConfig()
for funambol
[DEBUG] sync: /org/syncevolution/Server: auto sync: nothing to do
[DEBUG] sync: /org/syncevolution/Server: auto sync: updating info about config
target-config
[DEBUG] sync: /org/syncevolution/Server: auto sync: target-config: auto sync
'0', no Bluetooth, no HTTP, 1800 seconds repeat interval, 300 seconds online
delay
[DEBUG] sync: /org/syncevolution/Server: auto sync: reschedule, initConfig()
for target-config
[DEBUG] sync: /org/syncevolution/Server: auto sync: nothing to do
[DEBUG] sync: /org/syncevolution/Server: D-Bus server ready to run, versions:
[DEBUG] sync: /org/syncevolution/Server: backends: Loading backend library
/usr/lib/syncevolution/backends/platformkde.so
Loading backend library /usr/lib/syncevolution/backends/syncxmlrpc.so
Loading backend library /usr/lib/syncevolution/backends/syncfile.so
Loading backend library /usr/lib/syncevolution/backends/syncebook.so
Loading backend library /usr/lib/syncevolution/backends/synckcalextended.so
Loading backend library /usr/lib/syncevolution/backends/syncqtcontacts.so
Loading backend library /usr/lib/syncevolution/backends/syncactivesync.so
Loading backend library /usr/lib/syncevolution/backends/syncsqlite.so
Loading backend library /usr/lib/syncevolution/backends/syncdav.so
Loading backend library /usr/lib/syncevolution/backends/syncecal.so
Loading backend library /usr/lib/syncevolution/backends/syncaddressbook.so
Loading backend library /usr/lib/syncevolution/backends/syncakonadi.so
Loading backend library /usr/lib/syncevolution/backends/syncmaemocal.so
Loading backend library /usr/lib/syncevolution/backends/platformgnome.so
[DEBUG] sync: /org/syncevolution/Server: system:
[DEBUG] sync: /org/syncevolution/Server: version: 1.2.99.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/ld-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libc-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libdbus-1.so.3.7.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libdl-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libexpat.so.1.6.0
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libgcc_s.so.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libglib-2.0.so.0.3200.3
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libgpg-error.so.0.8.0
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/liblzma.so.5.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libm-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libpcre.so.3.13.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libpthread-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libresolv-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/librt-2.13.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/arm-linux-
gnueabi/libz.so.1.2.7
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/libcom_err.so.2.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/libkeyutils-1.2.so
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/libpng12.so.0.44.0
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/libselinux.so.1
[DEBUG] sync: /org/syncevolution/Server: watching: /lib/libusb-0.1.so.4.4.4
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libX11.so.6.3.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libatk-1.0.so.0.20409.1
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libbluetooth.so.3.12.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libcairo.so.2.11200.2
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libdbus-glib-1.so.2.2.2
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libfontconfig.so.1.5.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgconf-2.so.4.1.5
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgdk-x11-2.0.so.0.2400.10
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgdk_pixbuf-2.0.so.0.2600.1
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgio-2.0.so.0.3200.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgmodule-2.0.so.0.3200.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgnome-keyring.so.0.2.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgnutls.so.26.22.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgobject-2.0.so.0.3200.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgssapi_krb5.so.2.2
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgthread-2.0.so.0.3200.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libgtk-x11-2.0.so.0.2400.10
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libk5crypto.so.3.1
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libkrb5.so.3.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libkrb5support.so.0.1
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libnotify.so.4.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libp11-kit.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libpango-1.0.so.0.3000.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libpangocairo-1.0.so.0.3000.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libpangoft2-1.0.so.0.3000.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libpcrecpp.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libpixman-1.so.0.24.4
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libsoup-2.4.so.1.5.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libsqlite3.so.0.8.6
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libstdc++.so.6.0.17
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libxcb-shm.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/arm-linux-
gnueabi/libxml2.so.2.8.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXau.so.6.0.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libXcomposite.so.1.0.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libXcursor.so.1.0.2
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libXdamage.so.1.1.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXdmcp.so.6.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXext.so.6.4.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXfixes.so.3.1.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXi.so.6.1.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libXinerama.so.1.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libXrandr.so.2.2.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libXrender.so.1.3.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libcamel-1.2.so.33.0.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libcppunit-1.12.so.1.0.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libebook-1.2.so.13.3.1
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libecal-1.2.so.11.2.2
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libedataserver-1.2.so.16.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libffi.so.5.0.10
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libfreetype.so.6.6.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libgcrypt.so.11.5.3
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libgdbussyncevo.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libneon-
gnutls.so.27.2.3
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libnspr4.so.0d
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libnss3.so.1d
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libnssutil3.so.1d
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libopenobex.so.1.5.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libplc4.so.0d
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libplds4.so.0d
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libsmime3.so.1d
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libsmltk.so.0.6.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libssl3.so.1d
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libsyncevolution.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/libsynthesis.so.0.6.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libtasn1.so.3.1.9
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libxcb-
render.so.0.0.0
[DEBUG] sync: /org/syncevolution/Server: watching: /usr/lib/libxcb.so.1.1.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/platformgnome.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/platformkde.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncactivesync.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncaddressbook.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncakonadi.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncdav.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncebook.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncecal.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncfile.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/synckcalextended.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncmaemocal.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncqtcontacts.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncsqlite.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/backends/syncxmlrpc.so
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/lib/syncevolution/syncevo-dbus-server
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/local/lib/libical.so.0.44.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/local/lib/libicalss.so.0.44.0
[DEBUG] sync: /org/syncevolution/Server: watching:
/usr/local/lib/libicalvcal.so.0.44.0
[INFO] sync: /org/syncevolution/Server: ready to run
[DEBUG] sync: /org/syncevolution/Server: Error in calling DefaultAdapter of
Interface org.bluez.Manager: org.freedesktop.DBus.Error.ServiceUnknown: The
name org.bluez was not provided by any .service files
[DEBUG] sync: /org/syncevolution/Server: error in connmanCallback
org.freedesktop.DBus.Error.ServiceUnknown: The name net.connman was not
provided by any .service files
[DEBUG] sync: /org/syncevolution/Server: Error in calling Get of Interface
org.freedesktop.DBus.Properties : org.freedesktop.DBus.Error.ServiceUnknown:
The name org.freedesktop.NetworkManager was not provided by any .service files
What went wrong?
Regards
Christof
Am Donnerstag, 24. Januar 2013, 02:31:54 schrieb Christof Schulze:
Hi,
> That should also have been the error message on stdout:
> Doing a slow synchronization may lead to duplicated
> items or lost data when the server merges items incorrectly.
> Choosing a different synchronization mode may be the better
alternative.
> Restart synchronization of affected source(s) with one of the following
> sync modes to recover from this problem:
> slow, refresh-from-server, refresh-from-client
> Analyzing the current state:
> syncevolution --status funambol addressbook
> Running with one of the three modes:
> syncevolution --sync
> [slow|refresh-from-server|refresh-from-client]
> funambol addressbook
this was indeed visible on stdout.
> So to fix it temporarily, do a refresh sync as suggested. Note
that
> "from-client" will take the data from the WebDAV side.
Refreshing from server works, however upon the next regular run,
again
syncevolution reports an unexpected slow sync and the story starts
over again.
> It's impossible to say why it does that. One would have to
check the
> client and server side logs of the previous sync to figure out
> whether it really finished cleanly on both sides.
Funambol shows me these:
[2013-01-24 00:51:05,080] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Handling incoming request
[2013-01-24 00:51:05,244] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Request URL:
https://kdserv.dyndns.org:8443/funambol/ds
[2013-01-24 00:51:05,245] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Requested sessionId:
419E650606328E12C6751F0D2E1B1291
[2013-01-24 00:55:51,437] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Request processed.
[2013-01-24 00:59:54,248] [funambol.transport.http] [INFO]
[08500EFCEAA6AE7A528C7BBB9AEC1276] [192.168.142.54] [] [] [] Closing session
08500EFCEAA6AE7A528C7BBB9AEC1276
[2013-01-24 01:06:22,147] [funambol.transport.http] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Closing session
419E650606328E12C6751F0D2E1B1291
[2013-01-24 01:06:22,213] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] moving to state: STATE_ERROR
[Session aborted with status code: SESSION_EXPIRED]
[2013-01-24 01:06:22,236] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] moving to state: STATE_ENDED
[2013-01-24 01:06:22,237] [funambol.handler] [INFO]
[419E650606328E12C6751F0D2E1B1291] [10.126.0.1] [syncevolution-7d2d20c2-
ef1b-448e-9b21-5a24912aac74] [christof] [] Synchronization completed with
error(s)
I found a couple of remarks from 2010 on the web saying there is a
bug
in the oxtender but at this point I am probably better off, turning to a
funambol mailinglist.
> > Now I do not see a spot where the investigation should be
started:
> > This might be an issue with the data itself, syncevolution, funambol
> > or even a performance issue since syncevolution, funambol and the
> > webdav (owncloud) are running on the same hardware.
> May I ask what you need Funambol for? Perhaps Syncevolution
could do
> it?
Funambol is used because I want to be able to synchronize my nokia
e51
phone to my server at any time from anywhere.
However, and that is what I use syncevolution for, I would also like
my calendar from my nokie e51 to show up in a calendar in my owncloud
instance - hence the syncml-webdav-sync.
If that is possible with less hassle (at the moment it does not work
due to this kind of synchronisation issues) without using funambol -
perfect! What should I read to find out what to set up?
Christof
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
1:44 p.m.
On Tue, 2013-02-05 at 21:31 +0100, Christof Schulze wrote:
Hello,
the funambol configuration works now. All I did was to manuall start
the synchronisation for a couple of times while limiting the sync to
the addressbook and then again limiting it to the calendar.
However funambol is a memory hog (separate database, tomcat instance,
java application) hence I would like to replace it with something more
lightweight.
After having received feedback about using syncevo-http-server, I
tried to set things up according to https://syncevolution.org/wiki/http-
server-howto
When I try to synchronize just the addressbook datasource from the
phone the phone states that the server Url is invalid and the server
prints out the following error:
[ERROR] twisted: Unhandled Error
[...]
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.UnknownMethod: No
such interface `org.syncevolution.Server' on object at path
/org/syncevolution/Server
[...]
[DEBUG] sync: /org/syncevolution/Server: version: 1.2.99.1
[...]
What went wrong?
Probably a known and fixed timing issue with registering on D-Bus. You
are probably running Debian Testing?
Please install 1.3 from syncevolution.org, there's an apt repository.
It also doesn't hurt to file bugs against Debian. It's currently in
feature freeze, and getting things fixed depends on reporting them.
Otherwise the current version would be seen as working and stable.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
5:46 a.m.
Hi,
Probably a known and fixed timing issue with registering on D-Bus.
You
are probably running Debian Testing? Please install 1.3 from
syncevolution.org, there's an apt repository.
I was not able to use the
packages from the apt repository because there
were some blocks in the dependencies. The packages are called
differently in debian ie syncevolution-http for the server. However
compiling syncevolution 1.3.99.2 from source did indeed resolve the
issue.
The phone now reports successful synchronisation of the addressbook
however after a while I am seeing this in the server log:
[DEBUG] sync: /org/syncevolution/Session/7962587831360232313: starting GET,
credentials okay, deadline in 300.0s
[DEBUG] sync: /org/syncevolution/Session/7962587831360232313: starting GET,
credentials okay, deadline in 300.0s
[DEBUG] sync: /org/syncevolution/Session/7962587831360232313: starting GET,
credentials okay, deadline in 300.0s
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: timed out after 300s (state WAITING)
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: failed: timed out after 300s (old state WAITING)
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: send abort to client (state WAITING)
[DEBUG] syncevo-http: connection
/org/syncevolution/Connection/7962587831360232313 went down, active connection
/org/syncevolution/Connection/7962587831360232313
[DEBUG] syncevo-http: destructing connection
/org/syncevolution/Connection/7962587831360232313 with code 500 message lost
connection to SyncEvolution
[ERROR] dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in
maybe_handle_message
self._handler(*args, **kwargs)
File "/usr/local/bin/syncevo-http-server", line 154, in abort
self.destruct(http.INTERNAL_SERVER_ERROR, "lost connection to
SyncEvolution")
File "/usr/local/bin/syncevo-http-server", line 133, in destruct
self.connection.Close(False, message)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
DBusException: org.syncevolution.InvalidCall: cannot detach from resource that
client is not attached to
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: client :1.0 closes connection
/org/syncevolution/Connection/7962587831360232313 with error: lost connection
to SyncEvolution (old state FAILED)
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: exception thrown at
src/dbus/server/client.cpp:63
[ERROR] syncevo-dbus-server: /org/syncevolution/Server: cannot detach from
resource that client is not attached to
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: done with 'syncevo-server-http.py (HTTP)' unexpectedly:
timed out after 300s (old state FAILED)
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: Connection
7962587831360232313: not sending abort to client, already done (state FAILED)
[DEBUG] syncevo-dbus-server: /org/syncevolution/Server: activating idle
termination in 600 seconds because idle
[DEBUG] sync: /org/syncevolution/Session/7962587831360232313: starting GET,
credentials okay, deadline in 300.0s
This made me wonder whether all my data really has reached the webdav
storage however everything seems to be there.
Now all I have to do is to work up some faith to try two-way sync.
It also doesn't hurt to file bugs against Debian. It's
currently in
feature freeze, and getting things fixed depends on reporting them.
Otherwise the current version would be seen as working and stable.
Bug for debian
is filed on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699852
Thank you very much for your great work on syncevolution. This is
awesome!
Regards
Christof
Am Dienstag, 5. Februar 2013, 21:44:00 schrieb Patrick Ohly:
On Tue, 2013-02-05 at 21:31 +0100, Christof Schulze wrote:
> Hello,
> the funambol configuration works now. All I did was to manuall
start
> the synchronisation for a couple of times while limiting the sync to
> the addressbook and then again limiting it to the calendar.
> However funambol is a memory hog (separate database, tomcat
instance,
> java application) hence I would like to replace it with something more
> lightweight.
> After having received feedback about using syncevo-http-server,
I
> tried to set things up according to https://syncevolution.org/wiki/http-
> server-howto
> When I try to synchronize just the addressbook datasource from
the
> phone the phone states that the server Url is invalid and the server
> prints out the following error:
> [ERROR] twisted: Unhandled Error
[...]
> dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.UnknownMethod:
> No
> such interface `org.syncevolution.Server' on object at path
> /org/syncevolution/Server
[...]
> [DEBUG] sync: /org/syncevolution/Server: version: 1.2.99.1
[...]
> What went wrong?
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
6:18 a.m.
On Thu, 2013-02-07 at 13:46 +0100, Christof Schulze wrote:
Hi,
> Probably a known and fixed timing issue with registering on D-Bus. You
> are probably running Debian Testing? Please install 1.3 from
> syncevolution.org, there's an apt repository.
I was not able to use the packages from the apt repository because there
were some blocks in the dependencies.
You should be able to install "syncevolution-bundle" after or in
combination with removing all Debian SyncEvolution packages. I have the
syncevolution.org .deb installed on Debian Testing here.
This made me wonder whether all my data really has reached the
webdav
storage however everything seems to be there.
Now all I have to do is to work up some faith to try two-way sync.
Right, the logging is a bit strange. But the more important part is that
phone and the local engine believe that the session has ended normally.
You can check that with "syncevolution --print-sessions".
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3428
days inactive
3444
days old
syncevolution@synevolution.org
7 comments
2 participants
participants (2)
-
Christof Schulze -
Patrick Ohly