Created attachment 41260 [details] [review]
systemd install: Use -f for "ln"

We do want to overwrite an existing install; use case is "jhbuild"
type setup.

Created attachment 41261 [details] [review]
dbus-launch: Refactor duplicate code

De-duplicate execl() invocations of dbus-daemon.

Created attachment 41262 [details] [review]
Scope autolaunch to requesting client, don't connect to X server

Previously, when logging in via ssh with X forwarding, since
on most operating systems there is no DBUS_SESSION_BUS_ADDRESS,
we autolaunch a bus.  In this is that dbus-launch will
connect to the remote X server and scope itself to that, which
will cause ssh to refuse to exit because there are still clients.

Basically:
ssh -X remotehost
firefox &
<Control-d>

Now, scoping of the bus is a long debated mess, but there is
a reasonable fix for the ssh -X case; we scope the bus lifetime
to the requesting client, not to the X server.

This patch adds --exit-after-clients-exit option to the bus, which
will cause the bus, after an initial connection is made once, to exit
after it has no connections.

dbus-launch --autolaunch is modified to use this.  Now, in the
Firefox case what's actually going on is that it talks to GConf,
which was recently modified to scope to DBus, bus since no bus
is available it autolaunches one.  The resulting gconfd-2 process
hangs around after ssh exits, but will eventually time out.

Possible regressions:
* Previously dbus-launch looked at the X server to try to find
  a bus address; this worked in the "local" (i.e. same uid-kernel)
  case where one manually sets:
  DISPLAY=:0 somedbusapp
  A specific example of this case is the legacy Unix getty.  But
  I don't see this as a big problem; there are other environment
  variables, and really, the right fix for this is to have the
  OS default to single session.

Created attachment 41273 [details] [review]
updated patch

V2: Clean up dbus-launch.c even more to be sure we don't connect to X in autolaunch case.

DISPLAY=:0 some-dbus-command 

is very much used. You cannot remove this functionality.

(In reply to comment #5)
> DISPLAY=:0 some-dbus-command 
> 
> is very much used. You cannot remove this functionality.

Well, eventually my goal is just

"some-dbus-command" works (this gets back to OS single session).

I agree maintaining DISPLAY= setting for legacy gettys is desirable (I use it myself sometimes), though I don't see such a hard and fast "you cannot remove" rule for random Linux voodoo commands.

The question is - can we come up with a variation that "fixes" the ssh case without changing anything else?

It looks like recent versions of OpenSSH put "SSH_CONNECTION" in the environment; in that case, we could simply not connect to X.  We could also check inside dbus-launch for whether the X is remote, and if so ignore it.

However - if it comes down to "do we 'break' getty or do we 'unbreak' ssh", I think the latter really has to win.

What's wrong with ssh?

Yes, I have run programs with remote X sessions and they start D-Bus.

The only thing missing in the autolaunch implementation is "suicide mode" -- the server exit by itself when the last application disconnects. DCOP had this feature, but I don't see how useful this will be today unless applications also disconnect after a while. In KDE 4, they don't.

(In reply to comment #7)
> What's wrong with ssh?

Read the linked Red Hat bug in comment #1 .

> Yes, I have run programs with remote X sessions and they start D-Bus.
> 
> The only thing missing in the autolaunch implementation is "suicide mode" --
> the server exit by itself when the last application disconnects. DCOP had this
> feature, but I don't see how useful this will be today unless applications also
> disconnect after a while. In KDE 4, they don't.

If "a while" was "basically immediately", that might help this case; would require a gconf patch.

But I am looking for relatively noninvasive fixes at the moment, until we finally land singleton sessions.

(In reply to comment #8)
> (In reply to comment #7)
> > What's wrong with ssh?
> 
> Read the linked Red Hat bug in comment #1 .

Ok, so the daemon should exit after the apps exited.

> If "a while" was "basically immediately", that might help this case; would
> require a gconf patch.
> 
> But I am looking for relatively noninvasive fixes at the moment, until we
> finally land singleton sessions.

Singleton sessions won't solve the problem either because the current style of session busses will still exist. Adding a new functionality doesn't solve issues with existing functionality.

I think that the "suicide mode" is probably the best option: when the last application disconnects, the bus waits for a timeout and disconnects on its own. The timeout doesn't have to be long -- 5 seconds is probably long enough.

When the daemon exits, the X11 window is closed too.

(In reply to comment #9)
>
> Ok, so the daemon should exit after the apps exited.

That's the first part of my patch, yes.

But that still doesn't fix this case, because gconfd-2 will hang around; in general, any bus activated services.

> > If "a while" was "basically immediately", that might help this case; would
> > require a gconf patch.
> > 
> > But I am looking for relatively noninvasive fixes at the moment, until we
> > finally land singleton sessions.
> 
> Singleton sessions won't solve the problem either because the current style of
> session busses will still exist. 

In older operating system releases, yes.

> Adding a new functionality doesn't solve
> issues with existing functionality.

It would fix later operating systems.

> When the daemon exits, the X11 window is closed too.

Except as above, that's not good enough for this case.

My strong intuition is to simply axe off autolaunching entirely in the ssh case somehow.  It's really not desirable, since you can easily get e.g. multiple gconfd-2 processes stomping on each other.

(In reply to comment #10)
> (In reply to comment #9)
> >
> > Ok, so the daemon should exit after the apps exited.
> 
> That's the first part of my patch, yes.
> 
> But that still doesn't fix this case, because gconfd-2 will hang around; in
> general, any bus activated services.

That's a problem of those applications, not a D-Bus problem.

However, one thing we can do to help out is to introduce a "daemon connection" mode. The connections left in daemon mode are not counted towards "quit after last application exits". That way, these daemons quit after D-Bus itself quits, which is after the last non-daemon connection quits.

> > Singleton sessions won't solve the problem either because the current style of
> > session busses will still exist. 
> 
> In older operating system releases, yes.

We agreed not to remove the session bus. It will still exist in the model that it exists today.

> > Adding a new functionality doesn't solve
> > issues with existing functionality.
> 
> It would fix later operating systems.

It wouldn't because the current mode of sessions will still exist and be in use. Therefore, it's not a solution for the current mode of operation.

> > When the daemon exits, the X11 window is closed too.
> 
> Except as above, that's not good enough for this case.
> 
> My strong intuition is to simply axe off autolaunching entirely in the ssh case
> somehow.  It's really not desirable, since you can easily get e.g. multiple
> gconfd-2 processes stomping on each other.

But that would simply negate the use-case of why autolaunching was introduced, without replacing it with something else that solves the same problem.

The problem is to start applications that depend on D-Bus without D-Bus having been started. It was introduced mostly for the legacy case of desktop environments that didn't start D-Bus on their own (which was the rule back in 2006), but it's also true for X11-forwarded SSH sessions.

Havoc, any opinion here?

Historically, autolaunch was an important feature for KDE and we agreed to include it due to that, so I don't think we should break it if it's avoidable.

Having the bus exit when there are no connections, and allowing "daemon" connections that don't block exit, seem like useful features orthogonal to any big picture debate and even to whether autolaunch is enabled. If nothing else this would make a manual invocation work nicely:
 dbus-launch myapp
(which is what I usually do when using sudo I suppose)

Broader comment -

I feel like there's an unresolved big picture in this general area; the questions on the "what should happen with su/ssh" bug (too lazy to look up number) are still unresolved, and the "switch to one session per user per machine at a time" thread also just kind of ended without an agreed plan. I mean, nobody has ever fully spelled out a full, final answer on how all this should all work... and of course it's not coded either. It's endless piecemeal bugs until there's a document that covers *all* the things people think should work, proposing which will work, which get punted, and exactly how it all works... including potentially ugly pain like OS or openssh patches...

I'm thinking a document that tries to get all combinations of NFS homedir vs. not, su, "su -", sudo, ssh, X vs. console, multiple logins on one machine, interoperation with old Linux or Solaris, etc. - saying which work, which don't, and how they work so when they don't we can point to the root cause. And close stuff By Design while pointing to an actual design doc.

That said -

=> Please, never block on my opinion, though as you know I'm happy to add .02 to anything. :-P

This is fixed Ubuntu 16.10, haven't investigated where the fix came from.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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.freedesktop.org/dbus/dbus/issues/34.