Bug 76273 - activesyncd + error handling when D-Bus session is missing
Summary: activesyncd + error handling when D-Bus session is missing
Status: RESOLVED FIXED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: ActiveSync (show other bugs)
Version: 1.4
Hardware: x86 (IA32) Linux (All)
: medium blocker
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-17 15:07 UTC by Emiliano Heyns
Modified: 2014-07-14 14:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Logfile (11.89 KB, text/plain)
2014-03-19 13:24 UTC, Emiliano Heyns
Details
Activesyncd log (38.52 KB, text/plain)
2014-03-19 16:42 UTC, Emiliano Heyns
Details
Headless activesync (1.19 KB, text/plain)
2014-03-21 10:23 UTC, Emiliano Heyns
Details
output of go.sh (1.32 KB, text/plain)
2014-03-21 10:23 UTC, Emiliano Heyns
Details
dbus-session.sh + XDG_RUNTIME_DIR (4.99 KB, text/plain)
2014-03-21 12:48 UTC, Patrick Ohly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emiliano Heyns 2014-03-17 15:07:21 UTC
I'm trying to follow the instruction at https://syncevolution.org/wiki/ms-exchange-and-kde-synchronization:

email=emiliano.heyns@han.nl
username=staff\\hnse

gconftool --type string --set /apps/activesyncd/accounts/$email/serverUri 'https://weboffice.han.nl/Microsoft-Server-ActiveSync'
gconftool --type string --set /apps/activesyncd/accounts/$email/username $email
syncevolution --print-databases username=$email backend=eas-events

This gives me the error

[ERROR] : findCollections cannot allocate sync handler
Comment 1 Patrick Ohly 2014-03-17 15:58:26 UTC
How were SyncEvolution and activesyncd installed? What is your Linux distro?

The error indicates that a method in the libeas failed:

    handler = EasSyncHandlerCXX::steal(eas_sync_handler_new(account.c_str()));
    if (!handler) throwError("findCollections cannot allocate sync handler");

Please run:

SYNCEVOLUTION_DEBUG=1 syncevolution --print-databases loglevel=4 username=$email backend=eas-events

What's the output?
Comment 2 Emiliano Heyns 2014-03-17 16:02:32 UTC
[DEBUG 00:00:00] libeasclient: eas_sync_handler_new++ : account_uid[emiliano.heyns@han.nl]
[DEBUG 00:00:00] libeasclient: eas_sync_handler_class_init++
[DEBUG 00:00:00] libeasclient: eas_sync_handler_class_init--
[DEBUG 00:00:00] libeasclient: eas_sync_handler_init++
[DEBUG 00:00:00] libeasclient: eas_sync_handler_init--
[DEBUG 00:00:00] libeasclient: eas_sync_handler_finalize++
[DEBUG 00:00:00] libeasclient: eas_sync_handler_finalize--
[ERROR 00:00:00] : findCollections cannot allocate sync handler
Comment 3 Patrick Ohly 2014-03-17 18:52:20 UTC
Looks like this code inside eas_sync_handler_new is failing:

	if (! eas_gdbus_client_init(&object->priv->eas_client, account_uid, &error)) {
		g_object_unref (object);
		return NULL;
	}

Incidentally, that code fails to print the error and leaks it, which probably explains why there is no real error message.

Do you run syncevolution inside a D-Bus session with DBUS_SESSION_BUS_ADDRESS set?

syncevolution contacts activesyncd via D-Bus, and not being able to connect to D-Bus is the only way how eas_gdbus_client_init() can fail.

Indeed, I can reproduce the error when DBUS_SESSION_BUS_ADDRESS is not set and auto-launching D-Bus is impossible.

https://syncevolution.org/wiki/ms-exchange-and-kde-synchronization does not call out that requirement explicitly. It's implied in that HOWTO because it assumes that Akonadi and KDE are already working, which implies D-Bus.

For starting D-Bus, see for example this mail thread: http://permalink.gmane.org/gmane.comp.mobile.syncevolution/4568
Comment 4 Emiliano Heyns 2014-03-18 22:12:50 UTC
Sorry, I forgot to answer your earlier question: My system is a headless Ubuntu Saucy, updated weekly. That also answers your last question... no d-bus session running. I tried starting the print-databases command with the script at http://cgit.freedesktop.org/SyncEvolution/syncevolution/plain/test/dbus-session.sh, I now get:

[DEBUG 00:00:00] SuspendFlags: (re)activating, currently inactive
[DEBUG 00:00:00] SuspendFlags: activating signal handler(s) with fds 10->9
[DEBUG 00:00:00] SuspendFlags: catch signal 2
[DEBUG 00:00:00] SuspendFlags: catch signal 15
[ERROR 00:00:00] fetching folder list: GDBus.Error:org.meego.activesyncd.Error.Failed: HTTP request failed: 503 - Service Unavailable
[DEBUG 00:00:00] SuspendFlags: deactivating fds 10->9
[DEBUG 00:00:00] SuspendFlags: close m_receiverFD 9
[DEBUG 00:00:00] SuspendFlags: close m_senderFD 10
[DEBUG 00:00:00] SuspendFlags: done with deactivation
dbus-session.sh: program returned 1
dbus-session.sh: final result 1
+ [ !  ]
+ [ !  ]
+ [ ! 20700 ]
+ echo dbus-session.sh 20695: killing session bus daemon 20700
dbus-session.sh 20695: killing session bus daemon 20700
+ kill -9 20700
Comment 5 Patrick Ohly 2014-03-19 07:47:34 UTC
503 sounds like activesyncd is really talking to the ActiveSync server and getting that error back. Perhaps logs of activesyncd or the ActiveSync server explain that?

For local logging, set EAS_DEBUG and (to avoid flooding the console) EAS_DEBUG_FILE before running activesyncd.

For example:
dbus-session.sh bash
EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 <path>/activesyncd
syncevolution --print-databases ...
Comment 6 Emiliano Heyns 2014-03-19 08:46:52 UTC
When I run this:

export EAS_DEBUG=5
./dbus-session.sh /usr/libexec/activesyncd syncevolution --print-databases username=$email backend=eas-events

it produces only this (and doesn't return):

(process:27713:0x8fff400): activesyncd-DEBUG:activesyncd Daemon Started
(process:27713:0x8fff400): activesyncd-DEBUG:Creating eas_sync  gobject.
(process:27713:0x8fff400): activesyncd-DEBUG:++ eas_sync_init()
(process:27713:0x8fff400): activesyncd-DEBUG:-- eas_sync_init()
(process:27713:0x8fff400): activesyncd-DEBUG:Creating common  gobject.
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_class_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_class_init--
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_init--
(process:27713:0x8fff400): activesyncd-DEBUG:Creating mail  gobject.
(process:27713:0x8fff400): activesyncd-DEBUG:eas_mail_class_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_mail_class_init--
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_interface_base_init--
(process:27713:0x8fff400): activesyncd-DEBUG:eas_mail_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_mail_init--
(process:27713:0x8fff400): activesyncd-DEBUG:eas_test_new++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_test_class_init++
(process:27713:0x8fff400): activesyncd-DEBUG:eas_test_class_init--
(process:27713:0x8fff400): activesyncd-DEBUG:eas_test_init+-
(process:27713:0x8fff400): activesyncd-DEBUG:eas_test_new--
(process:27713:0x8fff400): activesyncd-DEBUG:Connecting to the session DBus
(process:27713:0x8fff400): activesyncd-DEBUG:Registering the well-known name (org.meego.activesyncd)
(process:27713:0x8fff400): activesyncd-DEBUG:D-Bus RequestName RPC
(process:27713:0x8fff400): activesyncd-DEBUG:RequestName returned 1
(process:27713:0x8fff400): activesyncd-DEBUG:Ready to serve requests
(process:27713:0x8fff400): activesyncd-DEBUG:Not daemonizing (built with DISABLE_EAS_DAEMON)
Comment 7 Patrick Ohly 2014-03-19 09:39:26 UTC
(In reply to comment #6)
> When I run this:
> 
> export EAS_DEBUG=5
> ./dbus-session.sh /usr/libexec/activesyncd syncevolution --print-databases
> username=$email backend=eas-events

Perhaps try this:

export EAS_DEBUG=5 SYNCEVOLUTION_DEBUG=1
./dbus-session.sh /usr/libexec/activesyncd syncevolution --daemon=no --print-databases username=$email backend=eas-events

That's a bit simpler because SyncEvolution doesn't try to move execution into syncevo-dbus-server. That should work, but who knows.

> it produces only this (and doesn't return):

Auto-launching activesyncd seems to work. No idea why there is no further output.
Comment 8 Emiliano Heyns 2014-03-19 09:56:47 UTC
That gives me this (script doesn't return):

(process:29105:0x8f98400): activesyncd-DEBUG:activesyncd Daemon Started
(process:29105:0x8f98400): activesyncd-DEBUG:Creating eas_sync  gobject.
(process:29105:0x8f98400): activesyncd-DEBUG:++ eas_sync_init()
(process:29105:0x8f98400): activesyncd-DEBUG:-- eas_sync_init()
(process:29105:0x8f98400): activesyncd-DEBUG:Creating common  gobject.
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_class_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_class_init--
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_init--
(process:29105:0x8f98400): activesyncd-DEBUG:Creating mail  gobject.
(process:29105:0x8f98400): activesyncd-DEBUG:eas_mail_class_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_mail_class_init--
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_interface_base_init--
(process:29105:0x8f98400): activesyncd-DEBUG:eas_mail_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_mail_init--
(process:29105:0x8f98400): activesyncd-DEBUG:eas_test_new++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_test_class_init++
(process:29105:0x8f98400): activesyncd-DEBUG:eas_test_class_init--
(process:29105:0x8f98400): activesyncd-DEBUG:eas_test_init+-
(process:29105:0x8f98400): activesyncd-DEBUG:eas_test_new--
(process:29105:0x8f98400): activesyncd-DEBUG:Connecting to the session DBus
(process:29105:0x8f98400): activesyncd-DEBUG:Registering the well-known name (org.meego.activesyncd)
(process:29105:0x8f98400): activesyncd-DEBUG:D-Bus RequestName RPC
(process:29105:0x8f98400): activesyncd-DEBUG:RequestName returned 1
(process:29105:0x8f98400): activesyncd-DEBUG:Ready to serve requests
(process:29105:0x8f98400): activesyncd-DEBUG:Not daemonizing (built with DISABLE_EAS_DAEMON)
Comment 9 Patrick Ohly 2014-03-19 10:47:44 UTC
(In reply to comment #6)
> When I run this:
> 
> export EAS_DEBUG=5
> ./dbus-session.sh /usr/libexec/activesyncd syncevolution --print-databases
> username=$email backend=eas-events

Sorry, I didn't spot the mistake. This command starts /usr/libexec/activesyncd with "syncevolution --print-databases username=$email backend=eas-events" as parameters. It then ignores the parameters and just keeps running.

What I had proposed is different: start a bash inside the D-Bus session, then the individual commands one-by-one. Each line is a single command.

dbus-session.sh bash
EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 /usr/libexec/activesyncd &
syncevolution --daemon=no --print-databases username=$email backend=eas-events
Comment 10 Emiliano Heyns 2014-03-19 13:24:44 UTC
Created attachment 96046 [details]
Logfile
Comment 11 Patrick Ohly 2014-03-19 14:48:30 UTC
You haven't told activesyncd about your password, have you? Normally it'll ask for it via ssh-askpass, but that won't work without X. 

You can temporarily set the password in gconf:

gconftool-2 --set --type=string /apps/activesyncd/accounts/$email/password $password

Then at runtime, activesyncd will move that password to GNOME keyring. For that to work, gnome-keyring must be started manually inside the D-Bus session.
Comment 12 Emiliano Heyns 2014-03-19 16:42:03 UTC
OK, done that; just so we're on the same page, here the full script I'm running inside the dbus bash session:

#!/bin/sh

email=emiliano.heyns@han.nl
username="staff\\hnse"
echo $password

gconftool --type string --set /apps/activesyncd/accounts/$email/serverUri 'https://weboffice.han.nl/Microsoft-Server-ActiveSync'
gconftool --type string --set /apps/activesyncd/accounts/$email/username "$username"
gconftool-2 --set --type=string /apps/activesyncd/accounts/$email/password $password
#SYNCEVOLUTION_DEBUG=1 syncevolution --print-databases loglevel=4 username=$email backend=eas-events

EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 /usr/libexec/activesyncd & syncevolution --daemon=no --print-databases username=$email backend=eas-events

(password is supplied by the environment). This generates the attached logfile, and ends in the following error:

[ERROR] fetching folder list: GDBus.Error:org.meego.activesyncd.Error.Failed: HTTP request failed: 401 - Unauthorized
Comment 13 Emiliano Heyns 2014-03-19 16:42:40 UTC
Created attachment 96056 [details]
Activesyncd log
Comment 14 Patrick Ohly 2014-03-19 17:13:12 UTC
(In reply to comment #12)
> OK, done that; just so we're on the same page, here the full script I'm
> running inside the dbus bash session:

You still don't have GNOME keyring running.

> #!/bin/sh
> 
> email=emiliano.heyns@han.nl
> username="staff\\hnse"
> echo $password
> 
> gconftool --type string --set /apps/activesyncd/accounts/$email/serverUri
> 'https://weboffice.han.nl/Microsoft-Server-ActiveSync'
> gconftool --type string --set /apps/activesyncd/accounts/$email/username
> "$username"
> gconftool-2 --set --type=string /apps/activesyncd/accounts/$email/password
> $password
> #SYNCEVOLUTION_DEBUG=1 syncevolution --print-databases loglevel=4
> username=$email backend=eas-events

Add this here:
/usr/bin/gnome-keyring &

> EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 /usr/libexec/activesyncd &
> syncevolution --daemon=no --print-databases username=$email
> backend=eas-events





> 
> (password is supplied by the environment). This generates the attached
> logfile, and ends in the following error:
> 
> [ERROR] fetching folder list:
> GDBus.Error:org.meego.activesyncd.Error.Failed: HTTP request failed: 401 -
> Unauthorized
Comment 15 Emiliano Heyns 2014-03-19 21:05:19 UTC
Allright. Starting

$ ./dbus-session.sh bash

now shows

GNOME_KEYRING_CONTROL=/run/user/1000/keyring-g51NwC
GNOME_KEYRING_PID=32508

If I then start the script below with:

password=xxxxxx ./setup.sh

I get 


(gnome-keyring:32540): Gtk-WARNING **: cannot open display:
** Message: couldn't initialize prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/lib/gcr/gcr-prompter exited with status 1
[ERROR] fetching folder list: GDBus.Error:org.meego.activesyncd.Error.Failed: HTTP request failed: 401 - Unauthorized

But I thought the 3rd gconftool call was supposed to store the password so gcr-prompter wouldn't be necessary? Could it be related perhaps to gconftool-2 being called rather than gconftool in the first two config commands?

===== script

#!/bin/sh

email=emiliano.heyns@han.nl
username="staff\\hnse"
echo $password

gconftool --type string --set /apps/activesyncd/accounts/$email/serverUri 'https://weboffice.han.nl/Microsoft-Server-ActiveSync'
gconftool --type string --set /apps/activesyncd/accounts/$email/username "$username"
gconftool-2 --set --type=string /apps/activesyncd/accounts/$email/password $password

/usr/bin/gnome-keyring &

EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 /usr/libexec/activesyncd & syncevolution --daemon=no --print-databases username=$email backend=eas-events
Comment 16 Patrick Ohly 2014-03-19 21:43:59 UTC
(In reply to comment #15)
> Allright. Starting
> 
> $ ./dbus-session.sh bash
> 
> now shows
> 
> GNOME_KEYRING_CONTROL=/run/user/1000/keyring-g51NwC
> GNOME_KEYRING_PID=32508

Right, I forgot that dbus-session.sh does it automatically if gnome-keyring-daemon (not gnome-keyring) is installed.

> If I then start the script below with:
> 
> password=xxxxxx ./setup.sh
> 
> I get 
> 
> 
> (gnome-keyring:32540): Gtk-WARNING **: cannot open display:
> ** Message: couldn't initialize prompt:
> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
> /usr/lib/gcr/gcr-prompter exited with status 1

Sorry, another unexpected prerequisite: the keyring must be usable without an explicit unlock via the UI.

I think this can be achieved by creating one in plain text; at least that is what I am using in the nightly testing:

$ cat ~/.gnome2/keyrings/default
default
nightly@syncev:~$ cat ~/.gnome2/keyrings/default.keyring
[keyring]
display-name=default
lock-on-idle=false
lock-after=false

> Could it be related perhaps to
> gconftool-2 being called rather than gconftool in the first two config
> commands?

On my Debian Wheezy, gconftool is an alias for gconftool-2, so no, that shouldn't matter.
Comment 17 Emiliano Heyns 2014-03-19 21:54:50 UTC
Right, they are.

I've created those files with (I think, I checked twice) the same content, but I still get 

** Message: couldn't initialize prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/lib/gcr/gcr-prompter exited with status 1
[ERROR] fetching folder list: GDBus.Error:org.meego.activesyncd.Error.Failed: HTTP request failed: 401 - Unauthorized


I truly do appreciate you sticking with this BTW.
Comment 18 Patrick Ohly 2014-03-20 13:12:29 UTC
(In reply to comment #17)
> ** Message: couldn't initialize prompt:
> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process
> /usr/lib/gcr/gcr-prompter exited with status 1

Is that still from the gnome-keyring-daemon? Just wondering.

Is there a chance to temporarily log into the server with X forwarding so that you can see what gcr-prompert is asking for?

> I truly do appreciate you sticking with this BTW.

I was more worried that you would give up ;-)

You are trying something that has not been attempted before and I am interested in getting it to work. I hope that once it works, you'll be able to write up a dedicated HOWTO.
Comment 19 Patrick Ohly 2014-03-20 14:55:13 UTC
I just had some spare cycles and tried it myself.

My environment is Debian Wheezy. activesyncd 0.92+20140218+SE+4613c97-1 and SyncEvolution 1.4 from syncevolution.org.

I created a test user and cleaned its home directory before doing a "sudo su - tester".

Then I created a keyring as discussed:

$ mkdir -p ~/.gnome2/keyrings/
$ echo default >~/.gnome2/keyrings/default
$ cat >~/.gnome2/keyrings/default.keyring <<EOF
[keyring]
display-name=default
lock-on-idle=false
lock-after=false
EOF
# gnome-keyring-daemon expects .cache to exist.
$ mkdir ~/.cache
$ mkdir ~/.config
$ dbus-session.sh bash
$ gconftool-2 --set --type=string /apps/activesyncd/accounts/${EXCHANGE_MAILADDR}/username "$EXCHANGE_USER"
$ gconftool-2 --set --type=string /apps/activesyncd/accounts/${EXCHANGE_MAILADDR}/serverUri "$EXCHANGE_URL"
$ gconftool-2 --set --type=string /apps/activesyncd/accounts/${EXCHANGE_MAILADDR}/password "$EXCHANGE_PASSWORD"
tester@pohly-mobl1:~$ find ~/
/home/tester/
/home/tester/.gconf
/home/tester/.gconf/apps
/home/tester/.gconf/apps/activesyncd
/home/tester/.gconf/apps/activesyncd/%gconf.xml
/home/tester/.gconf/apps/activesyncd/accounts
/home/tester/.gconf/apps/activesyncd/accounts/patrick.ohly@eas-testing.syncevolution.org
/home/tester/.gconf/apps/activesyncd/accounts/patrick.ohly@eas-testing.syncevolution.org/%gconf.xml
/home/tester/.gconf/apps/activesyncd/accounts/%gconf.xml
/home/tester/.gconf/apps/%gconf.xml
/home/tester/.gnome2
/home/tester/.gnome2/keyrings
/home/tester/.gnome2/keyrings/default
/home/tester/.gnome2/keyrings/default.keyring
/home/tester/.config
/home/tester/.cache
/home/tester/.cache/dconf
/home/tester/.cache/dconf/user
/home/tester/.cache/keyring-KfZAwm
/home/tester/.cache/keyring-KfZAwm/control
/home/tester/.bash_history
$ EAS_DEBUG_FILE=activesyncd.log EAS_DEBUG=5 /usr/libexec/activesyncd &
$ SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases username=${EXCHANGE_MAILADDR} backend=eas-events
...
eas-events:
   Calendar (1) <default>

The password was copied to the keyring:

$ cat ~/.gnome2/keyrings/default.keyring 
[keyring]
display-name=default
ctime=0
mtime=0
lock-on-idle=false
lock-after=false

[1]
item-type=1
display-name=ActiveSync Server Password for patrick.ohly@eas-testing.syncevolution.org@https://mail11.123together.com/Microsoft-Server-ActiveSync
secret=XXXXXXX
mtime=1395326548
ctime=0

[1:attribute0]
name=server
type=string
value=https://mail11.123together.com/Microsoft-Server-ActiveSync

[1:attribute1]
name=user
type=string
value=patrick.ohly@eas-testing.syncevolution.org
$ cat ~/.gconf/apps/activesyncd/accounts/patrick.ohly\@eas-testing.syncevolution.org/%gconf.xml 
<?xml version="1.0"?>
<gconf>
	<entry name="contact_folder" mtime="1395326570" type="string">
		<stringvalue>2</stringvalue>
	</entry>
	<entry name="calendar_folder" mtime="1395326570" type="string">
		<stringvalue>1</stringvalue>
	</entry>
	<entry name="policy_key" mtime="1395326570" type="string">
		<stringvalue>1578705214</stringvalue>
	</entry>
	<entry name="password" mtime="1395326414" type="string">
		<stringvalue>XXXXXXXXX</stringvalue>
	</entry>
	<entry name="serverUri" mtime="1395326413" type="string">
		<stringvalue>https://mail11.123together.com/Microsoft-Server-ActiveSync</stringvalue>
	</entry>
	<entry name="username" mtime="1395326413" type="string">
		<stringvalue>patrick.ohly@eas-testing.syncevolution.org</stringvalue>
	</entry>
</gconf>
$ grep password activesyncd.log 
(process:14026:0x1d3ae00): DEBUG:password changed: [XXXXX]
(process:14026:0x1d488a0): libeas-WARNING **:Found password in GConf, writing it to Gnome Keyring
(process:14026:0x1d3ae00): libeas-DEBUG:mainloop_password_store++
(process:14026:0x1d3ae00): libeas-DEBUG:mainloop_password_store--
(process:14026:0x1d3ae00): libeas-DEBUG:mainloop_password_fetch++
(process:14026:0x1d3ae00): libeas-DEBUG:mainloop_password_fetch--
(process:14026:0x1d488a0): libeas-DEBUG:Found password in Gnome Keyring
(process:14026:0x1d488a0): DEBUG:password changed: [XXXXXX]
Comment 20 Emiliano Heyns 2014-03-21 10:23:13 UTC
Created attachment 96148 [details]
Headless activesync
Comment 21 Emiliano Heyns 2014-03-21 10:23:49 UTC
Created attachment 96149 [details]
output of go.sh
Comment 22 Emiliano Heyns 2014-03-21 10:25:01 UTC
I've tried to capture your scenario in a script; I'm getting a permission denied error. This script was run in the context of a freshly setup user; the only thing I did was add the EXCHANGE variables to its .bashrc
Comment 23 Patrick Ohly 2014-03-21 10:43:31 UTC
Looks like Ubuntu Saucy needs XDG_RUNTIME_DIR (see 
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) set.

This is part of the normal user session setup and needs to be duplicated manually when starting a custom D-Bus session.

For now, you can do:
export XDG_RUNTIME_DIR=`mktemp -d`
before invoking dbus-session.sh. The directory can be removed when the session ends.

Eventually I'll probably have to add that to dbus-session.sh. I wonder whether that explains some of the random problems that I have seen with parallel testing on Saucy and Ubuntu: multiple different D-Bus sessions probably ended up using the same /run/user dir.
Comment 24 Emiliano Heyns 2014-03-21 11:31:29 UTC
Huzzah! No more errors! Does XDG_RUNTIME_DIR have to point to a temporary directory, or could I just run it against a fixed directory that I clear before run?

As soon as I sync set up, I'll definitely do a write-up. What is the best place for further discussion should I have questions?
Comment 25 Patrick Ohly 2014-03-21 11:51:36 UTC
(In reply to comment #24)
> Huzzah! No more errors! Does XDG_RUNTIME_DIR have to point to a temporary
> directory, or could I just run it against a fixed directory that I clear
> before run?

It can be a fixed directory, but it needs to be cleaned before running.

> As soon as I sync set up, I'll definitely do a write-up. What is the best
> place for further discussion should I have questions?

The mailing list (syncevolution at syncevolution.org) would be good.
Comment 26 Patrick Ohly 2014-03-21 12:48:35 UTC
Created attachment 96162 [details]
dbus-session.sh + XDG_RUNTIME_DIR

Here's the version of dbus-session.sh that I am currently testing. It creates and deletes the runtime dir in /tmp.

The directory can be in /tmp, it's content should be small.
Comment 27 Emiliano Heyns 2014-03-21 12:53:05 UTC
OK, that works. I'm getting 

g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.

after the tmp dir is removed, but I assume it's a harmless artifact at this point.
Comment 28 Patrick Ohly 2014-03-21 13:11:47 UTC
(In reply to comment #27)
> OK, that works. I'm getting 
> 
> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying
> GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
> 
> after the tmp dir is removed, but I assume it's a harmless artifact at this
> point.

Probably there was some process running which relied on D-Bus. Are you sure it's related to removing the XDG_RUNTIME_DIR and not jsut shutting down the D-Bus daemon?

As you said, it should be harmless.
Comment 29 Emiliano Heyns 2014-03-21 13:21:10 UTC
No, I'm not sure, I just didn't see it before. In anycase, it doesn't seem to affect syncevolution.
Comment 30 Patrick Ohly 2014-04-01 13:36:27 UTC
The updated dbus-session.sh script with XDG_RUNTIME_DIR is in master and SyncEvolution 1.4.1 (currently available as individual download and from the "unstable" repo on syncevolution.org).

I still need to enhance error handling in activesyncd, in particular the leak of the GError.
Comment 31 Patrick Ohly 2014-07-14 14:24:40 UTC
(In reply to comment #3)
> Looks like this code inside eas_sync_handler_new is failing:
> 
> 	if (! eas_gdbus_client_init(&object->priv->eas_client, account_uid,
> &error)) {
> 		g_object_unref (object);
> 		return NULL;
> 	}
> 
> Incidentally, that code fails to print the error and leaks it, which
> probably explains why there is no real error message.

Fixed in 

commit 674cf44cf9aaaaa6eb38eee8fa901796f3fef027
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Mon Jul 14 16:14:08 2014 +0200

    eassync: handle error when D-Bus is unavailable
    
    When D-Bus is unavailable and cannot be started,
    eas_sync_handler_new() neither printed the error nor did it clear it.
    Found as part of FDO #76273.


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.