Cleaning up owned dbus names on shutdown with glib

[David Zeuthen]

On Wed, Sep 28, 2011 at 10:28 AM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> 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.

Strong agreement on both suggestions.

>> [ 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.)

Like most other GLib code, GDBus uses g_warning() (or even
g_critical()) in a number of places where conditions that indicate
that a logical invariant has been violated or some other internal
warning. It's not impossible some of these checks are wrong - for
example, it should not spew if something fails because the connection
is closed. Stuff like that.

>> 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).

As I said in the other mail, let's wait for Daniel to file a bug in
the GLib bugzilla and we can debug it from there. Ideally we can write
a small test-case to reproduce this problem and then work on the
bugfix from there. Daniel, do you mind replying with the bugzilla
number when you file it? Thanks!

> 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.

Yup, I completely agree.

    David