`g_dbus_proxy_new_sync()` blocks for 25 seconds despite claiming to return immediately


I don’t know if this is a bug or if I’m misinterpreting the docs, so I’d rather open a thread here to start with.

The docs for g_dbus_proxy_new_sync() says that if the G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES and G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS flags are set, the function is supposed to return immediately without blocking.

However, following a bug report opened against Ristretto, I found that if Thunar fails to launch when creating a proxy for org.freedesktop.FileManager1, g_dbus_proxy_new_sync() blocks for 25 seconds despite the above flags.

I can reproduce this with an elementary program containing only

  GDBusConnection *connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, NULL);
  GDBusProxy *proxy = g_dbus_proxy_new_sync (connection,
                                           G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES |

and by editing Thunar’s systemd service file /usr/lib/systemd/user/thunar.service to replace

ExecStart=/usr/bin/Thunar --daemon


ExecStart=env DISPLAY=:1 /usr/bin/Thunar --daemon

to reproduce Thunar’s launch failure and the logs from the bug report quoted above.

I immediately get these logs:

sept. 12 17:16:33 pc dbus-daemon[602]: [session uid=1000 pid=602] Activating via systemd: service name='org.freedesktop.FileManager1' unit='thunar.service' requested by ':1.174' (uid=1000 pid=28983 comm="/home/user/p")
sept. 12 17:16:33 pc systemd[574]: Starting Thunar file manager...
sept. 12 17:16:33 pc thunar.orig[28987]: cannot open display: :1
sept. 12 17:16:33 pc systemd[574]: thunar.service: Main process exited, code=exited, status=1/FAILURE
sept. 12 17:16:33 pc systemd[574]: thunar.service: Failed with result 'exit-code'.
sept. 12 17:16:33 pc systemd[574]: Failed to start Thunar file manager.

then g_dbus_proxy_new_sync() hangs for 25 seconds.
Here’s a backtrace at the time of blocking:

#0  0x00007f4c5610359f in poll () at /usr/lib/libc.so.6
#1  0x00007f4c564c5206 in g_main_context_poll_unlocked (priority=2147483647, n_fds=1, fds=0x5600704af740, timeout=<optimized out>, context=0x5600704b00a0) at ../glib/glib/gmain.c:4653
#2  g_main_context_iterate_unlocked.isra.0 (context=0x5600704b00a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4344
#3  0x00007f4c56467b47 in g_main_loop_run (loop=0x5600704afbe0) at ../glib/glib/gmain.c:4551
#4  0x00007f4c566d2cbe in initable_init (initable=0x5600704b6b80, cancellable=<optimized out>, error=0x0) at ../glib/gio/gdbusproxy.c:1913
#5  0x00007f4c56631727 in g_initable_new_valist (object_type=<optimized out>, first_property_name=0x7f4c56724fcd "g-flags", var_args=var_args@entry=0x7ffef357a9a0, cancellable=0x0, error=0x0)
    at ../glib/gio/ginitable.c:250
#6  0x00007f4c5663180e in g_initable_new (object_type=<optimized out>, cancellable=<optimized out>, error=<optimized out>, first_property_name=<optimized out>) at ../glib/gio/ginitable.c:164
#7  0x00007f4c566d2eec in g_dbus_proxy_new_sync
    (connection=0x5600702d0610, flags=(G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES | G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS), info=0x0, name=0x56006ff7d02f "org.freedesktop.FileManager1", object_path=0x56006ff7d04c "/org/freedesktop/FileManager1", interface_name=0x56006ff7d02f "org.freedesktop.FileManager1", cancellable=0x0, error=0x0) at ../glib/gio/gdbusproxy.c:2103
#8  0x000056006ff7c23c in main ()

Is this normal or a bug?
Should I use g_dbus_proxy_new() rather than g_dbus_proxy_new_sync() to overcome this problem?


Well it’s guaranteed to return immediately without blocking, so I’d say blocking for 25 seconds is most definitely a bug. :stuck_out_tongue: Please report it here. If you can get a small reproducer that doesn’t depend on thunar, that would be best.

As for why it blocks for half a minute, it’s due to how Systemd activation is handled in DBus. See dbus-daemon: systemd activation failures are not detected (#458) · Issues · dbus / dbus · GitLab for more info. Basically it’s a disagreement between DBus and Systemd over when the ActivationFailure signal should be sent.

Yes indeed, thanks for the link. I couldn’t reproduce with files in ~/.local/share for some reason, but I have a minimal reproducer in /usr.
GitLab issue: GDBusProxy: g_dbus_proxy_new_sync() blocks for 25 seconds on systemd activation failure (#3110) · Issues · GNOME / GLib · GitLab