[X2Go-User] Questions about sessions

Les Mikesell lesmikesell at gmail.com
Wed Mar 4 18:16:20 CET 2015


On Wed, Mar 4, 2015 at 9:37 AM, Mihai Moldovan <ionic at ionic.de> wrote:
> >>>
>>> You cannot attach to running sessions, but you can forcefully suspend a
>>> running session from the client and then attach to it.
>> Is there some reason for that?   I preferred the NX/freenx approach
>> where the new connection would automatically grab the existing session
>> (since you obviously wouldn't be trying to reconnect if you already
>> had a running client on the computer you are currently using).
>
> I don't know. I can only guess, that running sessions are to be left
> alone (in case it's being worked on from some other machine)

In my case, it is always because I left it running on my work desktop,
forgetting to suspend when I left but now I want to pick the session
up from a different location (laptop or home Mac) and continue.

> and that in
> most cases a new session makes more sense than sharing a session. I also
> do not know how well session sharing works in general.
> (That's just not my use case, sorry.)

I don't want to share a session, I want to move it to the client where
I am now, resizing if necessary to fit.   NX/freenx handle this
wonderfully, but I don't like their current Mac client and freenx
isn't available for RHEL/Centos 7, so I'm hoping to be able to switch
to x2go for the same functionality.


>>> I don't like this, because it's inconvenient if you explicitly want to
>>> start a new session with the same characteristics. In my opinion, the
>>> session list should always be provided if one session (no matter the
>>> settings or state) is running on the server.
>> I disagree - I _always_ want to reconnect to my existing session,
>> across different clients and I'd rather not have to do unnecessary
>> work suspending/retrying or picking one session from a list of one
>> just because my laptop and mac screen sizes don't match my windows
>> desktop where the session was likely started.   If you are going to
>> change this behavior, can you please make it configurable so people
>> who only start one desktop session per host can always reconnect
>> without extra confusion, including automatically grabbing the session
>> you forgot to suspend before leaving your desk?
>
> There's one point you're missing: it is currently *impossible* to start
> a new session without knowing the exact workaround, if another session
> with the same characteristics is running.

Maybe add a checkbox option to force a new session?   If that's what
you want, then it won't matter whether or not one is already running.

> Maybe that's an edge case not concerning most users. When it comes to
> myself, I do need it quite often. For instance, I use to start multiple
> rootless xterm sessions for testing purposes when trying to reproduce
> bugs or test new features/whatnot and *don't* want to disturb other
> xterm sessions that are supposed to fulfill a particular purpose (e.g.,
> "video editing".)

I guess I don't understand why you would do that as opposed to letting
them run in a window manager session where they could open/close
without affecting each other yet still be easily picked up (together)
by a different client connection.  That is, work as though you were at
an X desktop at the console of a machine and grab the whole desktop to
your client.  If you are working on multiple nearby hosts, you can use
ssh X forwarding to get all of the windows on one desktop just like
you would if you were working there directly.

> If there is one xterm session started, it is currently impossible to
> start another one, without first starting some session that is not of
> xterm type.

Is that some internal quirk of x2go?   I guess I can understand why
you might want to start multiple new sessions doing rdp or with a
similar proxy approach to a different target.  But if you want
multiple windows on the same host, why not just let a window manager
session manage them with a single connection?

>> Aside from always wanting access to my same set of open windows and
>> long-running programs, I've had problems with  some desktop
>> environments and GUI applications with concurrent sessions for the
>> same user.   Some of them maintain hidden files that don't handle
>> concurrent updates gracefully, and some (like firefox) may try to open
>> a new instance as a new window in an already running session (which
>> may not be the one you are displaying).    So - starting a new session
>> if you already have one just seems wrong, especially if the session is
>> of the same desktop environment type.
>
> That's true for desktop sessions and specific applications which are
> supposed to be started only once, yes.
>
> There are valid reasons for multiple sessions, though, as outlined
> above. I can't say how widespread those use cases are, though. It may be
> only me, in the worst case, and I acknowledge that.

I can see having an option to force a new session even if one exists -
and maybe it makes sense in the context of single-application windows
if you want to manage them the hard way.  But, I'd just like to
minimize the extra steps you have to do to start up a client - and my
scenario will almost always be connecting to an already-running Gnome
or MATE desktop where I may or may not  have forgotten to disconnect
another client and the client where I am now may have different screen
geometry.

-- 
     Les Mikesell
       lesmikesell at gmail.com


More information about the x2go-user mailing list