| Summary: | activesyncd + error handling when D-Bus session is missing | ||
|---|---|---|---|
| Product: | SyncEvolution | Reporter: | Emiliano Heyns <emiliano.heyns> |
| Component: | ActiveSync | Assignee: | Patrick Ohly <patrick.ohly> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | medium | CC: | syncevolution-issues |
| Version: | 1.4 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Logfile
Activesyncd log Headless activesync output of go.sh dbus-session.sh + XDG_RUNTIME_DIR |
||
|
Description
Emiliano Heyns
2014-03-17 15:07:21 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?
[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 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
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 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 ... 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) (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. 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) (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 Created attachment 96046 [details]
Logfile
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. 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 Created attachment 96056 [details]
Activesyncd log
(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 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 (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. 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. (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. 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]
Created attachment 96148 [details]
Headless activesync
Created attachment 96149 [details]
output of go.sh
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 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. 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? (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. 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.
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. (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. No, I'm not sure, I just didn't see it before. In anycase, it doesn't seem to affect syncevolution. 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. (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.