[Bug 592434] Re: ssh -X user at machine hangs when using exit to terminate
Bug Watch Updater
592434 at bugs.launchpad.net
Fri Jul 26 13:45:58 UTC 2013
Launchpad has imported 14 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=32509.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2010-12-19T12:01:19+00:00 Colin Walters wrote:
See
https://bugzilla.redhat.com/show_bug.cgi?id=663467
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/7
------------------------------------------------------------------------
On 2010-12-19T12:02:55+00:00 Colin Walters wrote:
Created attachment 41260
systemd install: Use -f for "ln"
We do want to overwrite an existing install; use case is "jhbuild"
type setup.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/8
------------------------------------------------------------------------
On 2010-12-19T12:02:59+00:00 Colin Walters wrote:
Created attachment 41261
dbus-launch: Refactor duplicate code
De-duplicate execl() invocations of dbus-daemon.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/9
------------------------------------------------------------------------
On 2010-12-19T12:03:03+00:00 Colin Walters wrote:
Created attachment 41262
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/10
------------------------------------------------------------------------
On 2010-12-19T13:42:54+00:00 Colin Walters wrote:
Created attachment 41273
updated patch
V2: Clean up dbus-launch.c even more to be sure we don't connect to X in
autolaunch case.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/11
------------------------------------------------------------------------
On 2010-12-19T14:05:01+00:00 Thiago Macieira wrote:
DISPLAY=:0 some-dbus-command
is very much used. You cannot remove this functionality.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/12
------------------------------------------------------------------------
On 2010-12-19T16:09:33+00:00 Colin Walters wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/13
------------------------------------------------------------------------
On 2010-12-19T16:41:11+00:00 Thiago Macieira wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/14
------------------------------------------------------------------------
On 2010-12-19T17:20:12+00:00 Colin Walters wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/15
------------------------------------------------------------------------
On 2010-12-19T17:49:19+00:00 Thiago Macieira wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/16
------------------------------------------------------------------------
On 2010-12-20T07:29:38+00:00 Colin Walters wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/17
------------------------------------------------------------------------
On 2010-12-20T09:23:05+00:00 Thiago Macieira wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/18
------------------------------------------------------------------------
On 2010-12-20T13:25:31+00:00 Colin Walters wrote:
Havoc, any opinion here?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/19
------------------------------------------------------------------------
On 2010-12-20T15:24:51+00:00 Hp-pobox wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/592434/comments/20
** Changed in: dbus
Status: Unknown => Confirmed
** Changed in: dbus
Importance: Unknown => Medium
** Bug watch added: Red Hat Bugzilla #663467
https://bugzilla.redhat.com/show_bug.cgi?id=663467
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/592434
Title:
ssh -X user at machine hangs when using exit to terminate
Status in D-Bus:
Confirmed
Status in “dbus” package in Ubuntu:
Triaged
Bug description:
ssh -X user at server hangs when using exit to terminate
Steps to reproduce:
user at client:~$ ssh -X user at server
user at server:~$ gedit
At this point gedit from server will run locally. Closing the program
and returning to the terminal you run:
user at server:~$ exit
logout
At this point the terminal hangs on the echo logout, but does not return to the client prompt. The action has been consistent when connecting to a server running opensolaris or ubuntu 8.04.
The client is using Ubuntu 10.04 and the server is using 8.04, and using default password authentication. As you will see in the video attached I can confirm the issue when using a clean Ubuntu 10.04 as a client and Ubuntu 8.04 as the server, using default password authentication.
However there are a few things you can do to work around this issue.
-When logging out press Ctrl-D
-When logging out with "exit" and it hangs, press Ctrl-C
-If you would like to simply use gedit on another computer use the following command:
ssh -X lucas at machine gedit
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: openssh-server 1:5.3p1-3ubuntu3
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic-pae 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic-pae i686
Architecture: i386
Date: Thu Jun 10 17:34:26 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: openssh
To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/592434/+subscriptions
More information about the foundations-bugs
mailing list