Control: reassign -1 caja
On Fri, 16 Aug 2019 at 23:53:52 +0000, brian m. carlson wrote:
> On 2019-08-15 at 07:34:00, Simon McVittie wrote:
> > Control: tags -1 + moreinfo
> >
> > On Wed, 14 Aug 2019 at 23:48:09 +0000, brian m. carlson wrote:
> > > GTK+ produces the following warning when attempting to register a client
> > > with the session manager and the client is already registered:
> > >
> > > (caja:3729): Gtk-WARNING **: 02:59:57.229: Failed to register client:
> > > GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to
> > > register client
> >
> > Under what circumstances does this occur? I see the program in question
> > is caja. What desktop environment is this in, and how can this bug be
> > reproduced?
>
> This is in MATE with a typical mate-session startup. This message gets
> logged to ~/.xsession-errors, and it's trivially reproducible by running
> "killall caja". I believe I've seen it before when running from the
> command line, but I can't seem to reproduce that now.
This appears to be specific to caja. It looks as though it is registering
itself with the session manager twice: once via XSMP, and once via
GtkApplication's D-Bus API (as requested via the "register-session": TRUE
property at construct-time). I suspect that mate-session might not have
any reliable way to tell whether the two registrations are coming from
the same process (which would maybe be OK, albeit redundant) or whether
they are coming from different processes specifying the same opaque
"startup ID" (which would presumably result in the session manager having
difficulty managing them both separately). The D-Bus registration comes
from a D-Bus unique name, which can be resolved to a process ID by asking
the dbus-daemon; I don't know whether the XSMP registration carries similar
information or not.
I can reproduce this in a MATE desktop session in a VM. Other MATE apps
like atril and pluma don't seem to do this.
I can also reproduce it in a GNOME desktop session (with gnome-session
instead of mate-session) by running caja, but not by running nautilus,
the GNOME app from which caja was derived.
> > I don't know the session manager API well enough to know immediately
> > whether this message indicates a bug in the session manager, the
> > application, GTK, or something else.
>
> I see this much like reporting an ENOENT with unlink(2): what you wanted
> has already been done, so barring some specific circumstance where you
> know it will be a problem, there's no reason to report an error.
That's a good analogy: whether unlink(2) should be idempotent depends
on how it is being used. If you want it to be idempotent, then ENOENT
can be ignored, but if you are not expecting it to fail (for example
if you are using creation and deletion of a file as part of a locking
protocol), then it indicates a problem. That's why we have both rm, which
complains about ENOENT, and rm -f, which does not. A better analogy is
perhaps mkdir(2) rather than unlink: GtkApplication has been asked to
(tell the session manager to) create a record of its presence in the
session, but when it tried to do so, it received an error response
indicating that a record of the same startup ID already exists. Again,
callers of mkdir sometimes need to ignore EEXIST and sometimes need to
treat it as a problem, depending on precisely what they are doing.
If the maintainers of MATE's session manager do not consider it to be
problematic for the same application to register itself with the same
"startup ID" in two parallel ways, one option would be for mate-session to
respond to this situation with a D-Bus successful reply message instead
of with an error. (However, as noted above, it might not be practical for
mate-session to determine whether an XSMP registration and a D-Bus
registration are in fact describing the same process.)
On receiving an error, it seems reasonable for GTK to diagnose a potential
problem: it was asked to register using an opaque startup ID that was
meant to be unique, but got an error response from the session manager
when it tried to do so, indicating that the startup ID is already in use
to identify some other session manager client (which it appears may have
been because the same caja process also registered itself in parallel
using the same startup ID, EggSmClient and XSMP, but GtkApplication can't
know whether the process in which it is hosted is participating in XSMP
orthogonal to its use of GtkApplication with register-session set to TRUE).
smcv
