2 a.m.
Hi,
I tried the following:
syncevolution --configure autoSyncInterval=30 eazy
This command does not return. According to strace, it seems to wait
forever in poll().
Adding --daemon=no to the options does not hang.
Subsequent sync runs will also hang.
This happens with 1.3.1 with commit
d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
Regards,
Tino
2:12 a.m.
On Thu, Nov 22, 2012 at 11:00:56 +0100, tino.keitel+syncevolution(a)tikei.de wrote:
Hi,
I tried the following:
syncevolution --configure autoSyncInterval=30 eazy
This command does not return. According to strace, it seems to wait
forever in poll().
Adding --daemon=no to the options does not hang.
Subsequent sync runs will also hang.
This happens with 1.3.1 with commit
d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
It also happens with 1.2.99.1 from Debian Sid. I noticed that the
syncevo-dbus-helper process needs to be killed with SIGKILL after this,
SIGTERM won't suffice.
Regards,
Tino
3:05 a.m.
On Thu, 2012-11-22 at 11:12 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
On Thu, Nov 22, 2012 at 11:00:56 +0100,
tino.keitel+syncevolution(a)tikei.de wrote:
> Hi,
>
> I tried the following:
>
> syncevolution --configure autoSyncInterval=30 eazy
>
> This command does not return. According to strace, it seems to wait
> forever in poll().
>
> Adding --daemon=no to the options does not hang.
>
> Subsequent sync runs will also hang.
>
> This happens with 1.3.1 with commit
> d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
It also happens with 1.2.99.1 from Debian Sid. I noticed that the
syncevo-dbus-helper process needs to be killed with SIGKILL after this,
SIGTERM won't suffice.
I can't reproduce that here, using 1.3.1.
Is there perhaps a sync running while you invoke the command line?
Executing the command line will have to wait until syncing is complete.
To collect more information, please kill syncevo-dbus-server
and run it manually as
SYNCEVOLUTION_DEBUG=1 /usr/libexec/syncevo-dbus-server
Then in another shell try to set autoSyncInterval. That should show what
the server is waiting for.
Then when the helper gets stuck, what is the full stack backtrace? Just
poll inside g_main_loop_run()?
--
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:29 a.m.
On Thu, Nov 22, 2012 at 12:05:26 +0100, Patrick Ohly wrote:
On Thu, 2012-11-22 at 11:12 +0100,
tino.keitel+syncevolution(a)tikei.de
wrote:
> On Thu, Nov 22, 2012 at 11:00:56 +0100, tino.keitel+syncevolution(a)tikei.de wrote:
> > Hi,
> >
> > I tried the following:
> >
> > syncevolution --configure autoSyncInterval=30 eazy
> >
> > This command does not return. According to strace, it seems to wait
> > forever in poll().
> >
> > Adding --daemon=no to the options does not hang.
> >
> > Subsequent sync runs will also hang.
> >
> > This happens with 1.3.1 with commit
> > d4b85f9c621267974a9e741b2db142fb98db3ecf cherry-picked.
>
> It also happens with 1.2.99.1 from Debian Sid. I noticed that the
> syncevo-dbus-helper process needs to be killed with SIGKILL after this,
> SIGTERM won't suffice.
I can't reproduce that here, using 1.3.1.
Is there perhaps a sync running while you invoke the command line?
Executing the command line will have to wait until syncing is complete.
None that I know of.
To collect more information, please kill syncevo-dbus-server
and run it manually as
SYNCEVOLUTION_DEBUG=1 /usr/libexec/syncevo-dbus-server
The output is attached.
Then in another shell try to set autoSyncInterval. That should show what
the server is waiting for.
Then when the helper gets stuck, what is the full stack backtrace? Just
poll inside g_main_loop_run()?
It seems so:
(gdb) run
Starting program: /usr/bin/syncevolution --configure
autoSyncInterval=3M eazy
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecc37700 (LWP 30483)]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff5345e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff5345e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff6212624 in ?? () from
#/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff6212a82 in g_main_loop_run ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00000000004245b6 in SyncEvo::RemoteDBusServer::execute (
this=this@entry=0x7fffffffdee0, args=..., peer=...,
runSync=runSync@entry=false) at src/syncevolution.cpp:768
#4 0x000000000041e54d in SyncEvo::main (argc=4, argv=<optimized out>)
at src/syncevolution.cpp:500
(gdb)
The stack of syncevo-dbus-helper looks like this:
#0 0x00007f576b1a1e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f57685b7d30 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007f57685b6bfd in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007f57685a1904 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007f57685a29fa in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007f57660675aa in ?? ()
from /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0
#6 0x00007f576628e787 in SyncEvo::GNOMESavePasswordSlot (keyring=...,
passwordName=..., password=..., key=...)
at src/backends/gnome/GNOMEPlatform.cpp:118
So maybe it prompts for some password. I'll see if I get home. :-)
Regards,
Tino
5:31 a.m.
On Thu, Nov 22, 2012 at 14:29:21 +0100, tino.keitel+syncevolution(a)tikei.de wrote:
[...]
The stack of syncevo-dbus-helper looks like this:
#0 0x00007f576b1a1e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f57685b7d30 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007f57685b6bfd in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007f57685a1904 in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007f57685a29fa in ?? () from
#/lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007f57660675aa in ?? ()
from /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0
#6 0x00007f576628e787 in SyncEvo::GNOMESavePasswordSlot (keyring=...,
passwordName=..., password=..., key=...)
at src/backends/gnome/GNOMEPlatform.cpp:118
So maybe it prompts for some password. I'll see if I get home. :-)
Setting keyring=no in the global config fixes this issue.
Regards,
Tino
5:47 a.m.
New subject: [SyncEvolution] syncevolution --configure hangs - because of GNOME keyring
On Thu, 2012-11-22 at 14:31 +0100, tino.keitel+syncevolution(a)tikei.de
wrote:
On Thu, Nov 22, 2012 at 14:29:21 +0100,
tino.keitel+syncevolution(a)tikei.de wrote:
[...]
> The stack of syncevo-dbus-helper looks like this:
>
> #0 0x00007f576b1a1e33 in poll () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00007f57685b7d30 in ?? () from
> #/lib/x86_64-linux-gnu/libdbus-1.so.3
> #2 0x00007f57685b6bfd in ?? () from
> #/lib/x86_64-linux-gnu/libdbus-1.so.3
> #3 0x00007f57685a1904 in ?? () from
> #/lib/x86_64-linux-gnu/libdbus-1.so.3
> #4 0x00007f57685a29fa in ?? () from
> #/lib/x86_64-linux-gnu/libdbus-1.so.3
> #5 0x00007f57660675aa in ?? ()
> from /usr/lib/x86_64-linux-gnu/libgnome-keyring.so.0
> #6 0x00007f576628e787 in SyncEvo::GNOMESavePasswordSlot (keyring=...,
> passwordName=..., password=..., key=...)
> at src/backends/gnome/GNOMEPlatform.cpp:118
>
> So maybe it prompts for some password. I'll see if I get home. :-)
Setting keyring=no in the global config fixes this issue.
Yes, it probably got stuck waiting for user input. The libgnome-keyring
calls are all blocking.
SyncEvolution needs more INFO messages. It avoided them traditionally
because before 1.3, INFO messages became part of the output - not what
you want when dumping items to stdout. Since 1.3, the INFO goes to
stderr and thus it became possible to have more of it. That just hasn't
been added yet.
--
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.
2897
days inactive
2897
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Patrick Ohly -
tino.keitel+syncevolution＠tikei.de