GNOME Bugzilla – Bug 769841
gapplication: Add an org.gtk.Debugging interface
Last modified: 2018-05-24 19:02:12 UTC
The idea is that each application (or service) should provide a uniform external interface for enabling and disabling debug output — essentially a runtime equivalent of G_MESSAGES_DEBUG. This could be used by systemd and GNOME Builder to control debug output of processes without having to restart them. Currently, the interface suggestion is: <node> <interface name='org.gtk.Debugging'> <property name='EnableDebug' type='b' access='readwrite'/> </interface>" </node> I hope that eventually the interface could be renamed to org.freedesktop.Debugging once we're sure it's stable.
Created attachment 333225 [details] [review] gmessages: Expose a property for enabling debug message output This is an API analogue of the G_MESSAGES_DEBUG environment variable. It is intended to be exposed outside applications (for example, as a D-Bus interface — see follow-up commits) so that there is a uniform interface for controlling the debug output of an application.
Created attachment 333226 [details] [review] gapplication: Add an org.gtk.Debugging interface This is intended to provide a uniform interface for controlling whether the debug output from an application (or service) is emitted, typically to journald, but actually to wherever the application chooses to output it. This could be used by external harnesses, such as GNOME Builder or systemd, to give a uniform way to get debug output from an application. The interface is currently exported as org.gtk.Debugging, but eventually it is intended to be standardised cross-desktop as (perhaps) org.freedesktop.Debugging.
Lennart pointed out (while lounging by the GUADEC pool) that the property should probably be DebugEnabled, rather than EnableDebug (get rid of the verb). We considered exposing the log levels to output, rather than a boolean, but decided this was too big a hammer for no benefit. I was wondering about adding a ring buffer to the default GLib writer function (g_log_writer_default()), which could be dumped by calling org.gtk.Debugging.GetRecentLogs(), for the purposes of being able to grab some past context for program state, perhaps if it's hard to reproduce a bug (even without the need to restart the process). I was also wondering about an org.gtk.Debugging.DumpState() method which by default would do nothing, but which could be hooked up by an application to dump an a{sv} of any internal state it thinks would be interesting to developers. Both of those ideas are quite possibly architecture astronauting at the moment though. I think a decent implementation of them should probably be driven by what Builder wants to be able to extract from applications when running and debugging them.
After a bit more thought and some discussion with Dave (who is not in the GUADEC pool), I think it would be more useful than not to add a ring buffer in g_log_writer_default(), but I think DumpState() is a bit too esoteric.
I'd be carefull with adding such a ringbuffer... You'd just reimplement the journal, and you'd have to add a lot complexity to deal with concurrent thread-safe access to that log buffer (in particular if you want to ensure that logging works from signal handlers, which makes locking around this a nightmare). If we make the log level feature generic I'd be happy to support this in the lower levels of our stack too. I'd suggest defining an interface org.freedesktop.Debugging, with a read-only boolean property DebugLogging on an object /org/freedesktop/Debugging. It would be paired with a bus call SetDebugLogging() for altering it. Why not use a writable property? For system services write access to properties would have to be subject to authentication, and client-side libraries (such as GDBus) that cache properties heavily usually can't deal with failing property write accesses. If we however have an explicit function for this, this could even do interactive PK auth if it wants to (not that that would make a lot of sense...)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1190.