12:57 p.m.
Hi Patrick,
-----Ursprüngliche Nachricht-----
Von: "Patrick Ohly" <patrick.ohly(a)intel.com>
Gesendet: 25.10.2011 14:02:16
An: "Frederik Elwert" <frederik.elwert(a)web.de>
Betreff: Re: [SyncEvolution] syncevo-dbus-server dies - SIGPIPE
On Tue, 2011-10-25 at 13:41 +0200, Frederik Elwert wrote:
> >> 2. On my work machine, where I am still running Ubuntu Lucid, the
> >> syncevo-dbus-server fails silently. I could manage to sync using
> >> "--daemon=no", but for everyday use s-d-s is more comfortable.
SIGPIPE is triggered, apparently by a writev() inside libdbus.
SyncEvolution doesn't do anything with SIGPIPE. I wonder whether libdbus
expects that the process ignores it. The gdbus example does that.
Can you compile a test executable which adds the following lines to
SyncContext.cpp SyncContext::initMain()?
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
sigaction(SIGPIPE, &sa, NULL);
Finally, I managed to do so, and it seems it worked. I executed the newly comipled
syncevo-dbus-server, and then used the newly compiled syncevolution binary as a client.
Syncing worked over bluetooth. However, at the end I got the message "[ERROR] command
line execution failure". I don’t know of which kind this failure could be, since
everything seems to have worked just fine.
So with that little fix, bluetooth syncing with the built-in capabilities of the N9 seems
to be relatively easy. There is just one issue that I could not yet identify: There is
always a number of calendar entries in ERR state, which get re-submitted with the next
sync, and then again be rejected. On the N9, at a first glance no recent entries seem to
be missing, so I did not do too much to triage this issue. On the other hand, this
probably makes each sync use more time than necessary. Any ideas where these errors might
sttem from? I’ll send you a loglevel=4 log in private, maybe you can make more sense of it
than I can.
Regards,
Frederik
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
12:47 p.m.
New subject: [SyncEvolution] syncevo-dbus-server dies - SIGPIPE
On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
>On Tue, 2011-10-25 at 13:41 +0200, Frederik Elwert wrote:
>> >> 2. On my work machine, where I am still running Ubuntu Lucid, the
>> >> syncevo-dbus-server fails silently. I could manage to sync using
>> >> "--daemon=no", but for everyday use s-d-s is more
comfortable.
>SIGPIPE is triggered, apparently by a writev() inside libdbus.
>
>SyncEvolution doesn't do anything with SIGPIPE. I wonder whether libdbus
>expects that the process ignores it. The gdbus example does that.
>
>Can you compile a test executable which adds the following lines to
>SyncContext.cpp SyncContext::initMain()?
>
> struct sigaction sa;
> memset(&sa, 0, sizeof(sa));
> sa.sa_handler = SIG_IGN;
> sigaction(SIGPIPE, &sa, NULL);
Finally, I managed to do so, and it seems it worked. I executed the
newly comipled syncevo-dbus-server, and then used the newly compiled
syncevolution binary as a client. Syncing worked over bluetooth.
However, at the end I got the message "[ERROR] command line execution
failure". I don’t know of which kind this failure could be, since
everything seems to have worked just fine.
If you run the syncevo-dbus-server in a shell window with
SYNCEVOLUTION_DEBUG=1 set as env variable, does it print anything? Does
it perhaps crash again?
So with that little fix, bluetooth syncing with the built-in
capabilities of the N9 seems to be relatively easy. There is just one
issue that I could not yet identify: There is always a number of
calendar entries in ERR state, which get re-submitted with the next
sync, and then again be rejected. On the N9, at a first glance no
recent entries seem to be missing, so I did not do too much to triage
this issue. On the other hand, this probably makes each sync use more
time than necessary. Any ideas where these errors might sttem from?
Most likely the device rejects certain events because it cannot parse
them properly.
I’ll send you a loglevel=4 log in private, maybe you can make more
sense of it than I can.
I'll have a look.
--
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:30 p.m.
New subject: [SyncEvolution] N9 Bluetooth sync incomplete, 500 status for Delete (was: Re: syncevo-dbus-server dies - SIGPIPE)
On Mon, 2011-10-31 at 13:57 +0100, Frederik Elwert wrote:
There is just one issue that I could not yet identify: There is
always
a number of calendar entries in ERR state, which get re-submitted with
the next sync, and then again be rejected. On the N9, at a first
glance no recent entries seem to be missing, so I did not do too much
to triage this issue. On the other hand, this probably makes each sync
use more time than necessary. Any ideas where these errors might sttem
from? I’ll send you a loglevel=4 log in private, maybe you can make
more sense of it than I can.
The failures are all for item delete requests. The N9 returns a very
uninformative 500, which is usually about an internal error. Because the
Synthesis engine doesn't know what to do about that, it keeps trying.
Can you do a refresh sync? I assume your desktop has all your events, so
do a '--sync refresh-from-server' on the desktop (which is the server in
this case).
If that doesn't help, try a '--sync slow', but beware of unintentional
data changes on the desktop. Use '--restore --before' if something
undesirable happened during the slow sync, then continue with a normal
sync.
To determine what may have caused the issue I would need also the log
file right before the problem started to appear. Let's look into that if
the refresh (or slow) sync don't help, okay?
There's really not much that can be done wrong with a delete request. It
only passes an ID to the device, so either the ID is valid or it is not.
If the ID no longer corresponds to an item, the device should return 404
or (better) simply acknowledge that the item is gone.
--
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.
3848
days inactive
3850
days old
syncevolution@synevolution.org
2 comments
2 participants
participants (2)
-
Frederik Elwert -
Patrick Ohly