Cleaning up owned dbus names on shutdown with glib

[Simon McVittie]

On Wed, 28 Sep 2011 at 15:05:10 +0100, Daniel Drake wrote:
> 1. imsettings receives SIGTERM, which it has a handler for
> 2. The SIGTERM handler asks the glib main loop to quit
> 3. After the glib main loop ends, imsettings main() destroys its
> IMSettingsServer object, which is what was owning the bus name
> 4. imsettings_server_finalize() calls g_bus_unown_name() which then
> hangs for 5-20 seconds, then complains:

I don't think you need to do this at all. If you just disconnect
from the dbus-daemon - or even simpler, just exit - dbus-daemon will detect
that you have disconnected, and emit the same NameOwnerChanged signal that
it would if you'd explicitly dropped the name. (Or at least, it would if it
hadn't died itself.)

I'm not even sure that you need to, or should, handle SIGTERM at all - unless
you particularly need to do some special cleanup, I'd advise just letting it
kill you.

> [ 1317208397.833711]: GLib-GIO[2630]: WARNING **: Error releasing name
> com.redhat.imsettings: Timeout was reached
> 
> [ 1317208397.834972]: GLib-GIO[2630]: CRITICAL **: Error while sending
> AddMatch() message: The connection is closed

I think it's a bug if GDBus spams to stderr with g_warning() or g_critical()
when using a closed connection, though - it should report errors gracefully,
and let you deal with them yourself. (Or perhaps I'm misinterpreting those
log messages and they're actually *your* code calling g_warning() or
g_critical()? If so, that's fine.)

> If I add a call to g_dbus_connection_close_sync() before trying to
> unown the name, shutdown completes instantaneously.

Do that, then? Disconnecting from D-Bus guarantees that all of your names
are released, and that you won't receive any more messages (apart from
possibly any that were already queued in your incoming socket buffer).

> However, that doesn't seem like the right fix. Ordinarily, outside of
> the shutdown path, if imsettings receives SIGTERM it should unown its
> bus name and exit cleanly, and it wouldn't be able to do this if the
> preceding code had just closed the connection.

Define "exit cleanly"? Just disconnecting from D-Bus is usually the cleanest
thing to do. If another process doesn't cope with that, then it's buggy,
because it wouldn't cope with your service crashing either.

> So I am wondering if I have found a bug in the dbus message sending
> internals of glib. [...] approximately at the same time as when
> it tries to unown the name, the session bus gets killed. This causes
> the unown call to hang for a long time.

Possibly GDBus is waiting for the reply to ReleaseName, and not paying
attention to disconnection? It should consider name-releasing to have finished
if either it gets a reply (or error), or it gets disconnected (e.g. by the
death of the dbus-daemon). But you'd avoid this entirely if you didn't make
life hard for yourself by trying to shut down more gracefully than is really
required.

    S