Hi,
I feel awkward asking these since I am a developer.
What are the differences between a session that is "suspend" and a session that is "running" but disconnected?
With X2Go Client for Windows at least, sometimes I will connect to an X2go Server and I will see 1 running or suspended session listed in the Qt4 GUI. Other times, I connect and it automatically connect me to the existing session. What causes this behavior?
BTW, there are FIXMEs on this page: http://wiki.x2go.org/doku.php/wiki:advanced:x2goserver-in-detail
-Mike#2
On 03.03.2015 03:36 PM, Michael DePaulo wrote:
I feel awkward asking these since I am a developer.
- What are the differences between a session that is "suspend" and a session that is "running" but disconnected?
A suspended session has been gracefully suspended within the client.
A running session could either be an active one currently used, or one that is still waiting for a timeout of the client crashed or the connection was dropped prematurely for any reason. Running sessions should switch into suspended state after a (rather long?) timeout.
You cannot attach to running sessions, but you can forcefully suspend a running session from the client and then attach to it.
- With X2Go Client for Windows at least, sometimes I will connect to an X2go Server and I will see 1 running or suspended session listed in the Qt4 GUI. Other times, I connect and it automatically connect me to the existing session. What causes this behavior?
Personally, I don't like this behavior. I'll though explain what's going on:
If no session exists on the server, a new one is created and automatically attached to (well, pretty obvious case.)
If there is a suspended session, there multiple two cases: 1.) the session you currently want to start matches the already existing, suspended session (same settings, including the "application"/"desktop" to start) => this session will then be attached to without prior notification, you will NOT see the session list beforehand 2.) the session to start matches a "running" session on the server. You will be presented with the list (and able to forcefully suspend the running session, if that's what you're after.) 3.) the new session differs in session setting details. In this case, you will get the session list.
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.
Mihai
On Tue, Mar 3, 2015 at 8:56 AM, Mihai Moldovan <ionic@ionic.de> wrote:
On 03.03.2015 03:36 PM, Michael DePaulo wrote:
I feel awkward asking these since I am a developer.
- What are the differences between a session that is "suspend" and a session that is "running" but disconnected?
A suspended session has been gracefully suspended within the client.
A running session could either be an active one currently used, or one that is still waiting for a timeout of the client crashed or the connection was dropped prematurely for any reason. Running sessions should switch into suspended state after a (rather long?) timeout.
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).
If there is a suspended session, there multiple two cases: 1.) the session you currently want to start matches the already existing, suspended session (same settings, including the "application"/"desktop" to start) => this session will then be attached to without prior notification, you will NOT see the session list beforehand 2.) the session to start matches a "running" session on the server. You will be presented with the list (and able to forcefully suspend the running session, if that's what you're after.) 3.) the new session differs in session setting details. In this case, you will get the session list.
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?
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.
-- Les Mikesell lesmikesell@gmail.com
On 03.03.2015 06:03 PM, Les Mikesell wrote:
On Tue, Mar 3, 2015 at 8:56 AM, Mihai Moldovan <ionic@ionic.de> wrote:
A suspended session has been gracefully suspended within the client.
A running session could either be an active one currently used, or one that is still waiting for a timeout of the client crashed or the connection was dropped prematurely for any reason. Running sessions should switch into suspended state after a (rather long?) timeout.
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) 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.)
If there is a suspended session, there multiple two cases: 1.) the session you currently want to start matches the already existing, suspended session (same settings, including the "application"/"desktop" to start) => this session will then be attached to without prior notification, you will NOT see the session list beforehand 2.) the session to start matches a "running" session on the server. You will be presented with the list (and able to forcefully suspend the running session, if that's what you're after.) 3.) the new session differs in session setting details. In this case, you will get the session list.
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 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".)
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.
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.
Mihai
On Wed, Mar 4, 2015 at 9:37 AM, Mihai Moldovan <ionic@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@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 03.03.2015 um 15:56 schrieb Mihai Moldovan:
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.
Middle path (only possible if the behavior is triggered by x2goclient, not x2goserver): Add a per-session checkbox "auto-reattach". If it is checked, a matching session will reattach. If it is not checked, it will present the list, even if a matching session exists.
Make it a "priority: wishlist" bug if you want. :)
- -Stefan
BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJU9jI3AAoJEG7d9BjNvlEZLbwIAIAm9+xDM7edI1LOaDP/TpSR D/eVxP8k+RNVjbn+1D7b7eWn6W81wqNu0nDLJTMR8w1wHyKL2xYXQq1VvWLyKYGU UFFXa/xsiR5RFIi4Qi3bA9PGJiEQ86rJA0pDcZBxri02VnE0DyZXWqRf60Jm8DRA dxmGeFCSEBpJ2CYzPiIxOibBY02WTInJw9TraxGrVsOCNCCJIIY15aMUzbAoNNkV 9i6LHl1LpwrnXI3ZBSD66ia5ytvvNUB840sk5HmzRNcY98N01q20Ie9S2setsKIR 17DVstjFP5/7OPUjgeAyTc6UATskLwQwZlICrWN5znj4OUZmDZyvl1MZJWEqL48= =DyDj -----END PGP SIGNATURE-----
Hi all,
On Di 03 Mär 2015 15:56:54 CET, Mihai Moldovan wrote:
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.
IIRC, you can righ-click on the session card in X2Go Client and then
you _always_(TM) get the running/suspended session selector widget
before actually connecting to the session.
I just heard that once from Heinz or Alex, never verified it, though.
Furthermore, I think we face different use cases here.
I agree with Mihai, that it is awkward, landing in a session that one
maybe does not want. I often run multiple sessions of the same desktop
type for the same user. More often, multiple sessions of different
session types for the same user (which also fails due to X2Go Client
auto-connecting). However, I am not bothered by that isssue as I use
PyHoca-GUI, not X2Go Client.
So, for X2Go Client as a thin client in multi-user environments, you
surely surely what the session auto-resuming behaviour. Also on
machines that have smart card readers in place for authentication.
Various setups that we have to consider here.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 05.03.2015 09:08 AM, Mike Gabriel wrote:
IIRC, you can righ-click on the session card in X2Go Client and then you _always_(TM) get the running/suspended session selector widget before actually connecting to the session.
I just heard that once from Heinz or Alex, never verified it, though.
If that's true and actually working, there's really no need to change the current behavior... but we really should keep a record of this feature and maybe even change it into a checkbox on the session widget (right-clicking is sometimes an adventure on touchpads and I figure almost no one will instinctively try to right-click to always get the session selection window.)
Mihai
On Thu, Mar 5, 2015 at 2:08 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
I agree with Mihai, that it is awkward, landing in a session that one maybe does not want. I often run multiple sessions of the same desktop type for the same user.
Don't you run into trouble with applications clobbering their own hidden files or things like firefox launching what you expected to be a new instance as a window in one of the suspended sessions instead? And when reconnecting, how do you distinguish which session you want?
-- Les Mikesell lesmikesell@gmail.com
Hi,
----- Original message -----
On Thu, Mar 5, 2015 at 2:08 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
I agree with Mihai, that it is awkward, landing in a session that one maybe does not want. I often run multiple sessions of the same desktop type for the same user.
Don't you run into trouble with applications clobbering their own hidden files or things like firefox launching what you expected to be a new instance as a window in one of the suspended sessions instead? And when reconnecting, how do you distinguish which session you want?
The simple answer is: I use PyHoca-GUI. That makes things much easier.
And, I am good at remembering session Ids and numbers.
Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148
GnuPG Key ID 0x25771B13 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
On Thu, Mar 5, 2015 at 3:39 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
I agree with Mihai, that it is awkward, landing in a session that one maybe does not want. I often run multiple sessions of the same desktop type for the same user.
Don't you run into trouble with applications clobbering their own hidden files or things like firefox launching what you expected to be a new instance as a window in one of the suspended sessions instead? And when reconnecting, how do you distinguish which session you want?
The simple answer is: I use PyHoca-GUI. That makes things much easier.
And, I am good at remembering session Ids and numbers.
I guess the thing I am really missing is 'why'? I use x2go as a substitute for sitting at an X console and can't think of a reason why I'd want to plug in another real console on the same machine to log in as the same user. Is there some advantage to concurrent sessions that you wouldn't get from Gnome's virtual screens or similar approaches to clutter reduction?
-- Les Mikesell lesmikesell@gmail.com
On 05.03.2015 10:29 PM, Les Mikesell wrote:
Don't you run into trouble with applications clobbering their own hidden files or things like firefox launching what you expected to be a new instance as a window in one of the suspended sessions instead? And when reconnecting, how do you distinguish which session you want?
I do not. But this is merely because I am not starting multiple desktop sessions at a time or applications that do not support concurrency, but "plain" stuff like xterms or the like.
I'll give an example:
Currently, I have a session running on my server for "video editing" purposes. This session is rootless and consists of 3 xterms, from which I start a video player (mpv) every now and then or edit text files or move stuff around. I do not want to use this session but merely for this "video editing".
This said, when working on x2goclient or x2goserver, I have to start a new session quite often. Maybe because some issue I'm looking into is dependent on x2goserver's or x2goclient's behavior *when starting a session* or because I have to explicitly test a non-rootless mode (like custom desktop via fluxbox.)
I also have another session with xterms and an application running exclusively for some other, undisclosed purpose.
For my use case, I want the terminals and applications to be independent from each other and I don't really use a desktop session or browser regularly.
This use case is totally different from your thinclient-like use case. And that's fine. You want integration, I want isolation. X2Go is supposed to support both. We really try to satisfy all reasonable/generic use cases.
Mihai
On Thu, Mar 5, 2015 at 3:46 PM, Mihai Moldovan <ionic@ionic.de> wrote:
For my use case, I want the terminals and applications to be independent from each other and I don't really use a desktop session or browser regularly.
This use case is totally different from your thinclient-like use case. And that's fine. You want integration, I want isolation. X2Go is supposed to support both. We really try to satisfy all reasonable/generic use cases.
Yes, it just seems odd to me to use multiple x2go sessions as the same user instead of a window manager or desktop environment - or for that matter, to do things differently than you would if you were logged in at the physical console. But my point is just that I'd like to see the 'extra' steps to connect minimized as much as possible and to make picking up running sessions on a different client as easy as it was with NX.
-- Les Mikesell lesmikesell@gmail.com
-
Les Mikesell -
Michael DePaulo -
Mihai Moldovan -
Mike Gabriel -
Stefan Baur