[X2Go-User] Client handling of downed server

Thu Jan 22 19:31:47 CET 2015

WAIT - operator error - I had another machine w/the same static IP on 
the switch.

Obviously a big problem.  Please discount the below and I promise 
self-flagellation for not thinking before posting...

- PB

On 01/22/2015 10:29 AM, Peter Brodsky wrote:
> This is getting worse.  Now, for reasons I don't understand, my client 
> session freezes.
> Eventually it pops up a window saying the server is not responding and 
> asks me if I want to terminate the session.  I say yes. Nothing happens.
>
> Then I go back to the main X2Go client window and hit the "terminate" 
> button (the round one in the lower right of the gray rectangular 
> window inside the blue area).  It asks if I want to terminate.  I say 
> yes.  Nothing happens.
> Eventually another window pops up and tells me the server session has 
> been killed, and indeed that window goes away.  Now the client is 
> stuck in a mode with a rotating wheel and a message "x2goclient.exe 
> has stopped working" and a button:  "Close program".  I hit that 
> button and it finally all goes away.
>
> So then I try again from scratch.  Immediately get a popup: "Socket 
> error:  Unknown error".  I hit OK.
> Hit "Cancel".  Try again.  Now it's hung (no message, no session).
> Only way to kill it is via the big red X in the upper right of the 
> client window.
>
> - Pete
>
>
> On 01/14/2015 10:31 AM, Stefan Baur wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 14.01.2015 um 19:01 schrieb Peter Brodsky:
>>> For example, I mistakenly try to open a session to a (linux)
>>> server which is not powered up, the (Windows) client simply sits
>>> and tries. There's no way to cancel.  Clicking on the small round
>>> on/off button in the session window (the rectangular one that lands
>>> in the left/blue area) does not take.  I simply have to wait until
>>> it times out.  Could this not be dealt with more actively?
>>> Obviously this is a "don't do that" kind of thing, but it does
>>> happen.
>> You could file a wishlist bug for that, and see if one of our
>> volunteer devs picks up on it, or someone steps up and offers to fix
>> it for a price.
>>
>> To do so, send an eMail to submit at bugs.x2go.org,
>> subject: something descriptive, like "add cancel button for
>> 'connecting' phase",
>> first two lines of the eMail must be ...
>> package: x2goclient
>> severity: wishlist
>>
>> leave one blank line after that, just like I did here,
>> then add a description, e.g. you could just copy and paste the
>> paragraph of your eMail that I quoted above.
>>
>>
>>> Also, if the server is shut down from the client window (which is
>>> the case for us because we're effectively headless), then the
>>> client "sort of" hangs again.  Trying to kill the active session
>>> window by clicking the red X in the upper right does nothing.
>>> Eventually I get a notice that the server is incommunicado and asks
>>> if I want to terminate th current session. Would be nice if there
>>> were a cleaner way to handle this.
>> Well, ordinary users should not be able to shut down the server
>> remotely.  So for our regular use cases, this isn't an issue.
>>
>> To shut down the server remotely, assuming you have sufficient
>> permissions, I would suggest the following script on the server (you
>> can place a shortcut to it on the desktop if you like), probably best
>> stored in /usr/local/sbin/ or /usr/local/bin/:
>>
>> #!/bin/bash
>> (sleep 10 && poweroff) &
>> disown
>> x2goterminate-session
>>
>> If the account you're using for X2Go remoting doesn't have sufficient
>> permissions to run the poweroff command, I suggest installing sudo (if
>> not already present) and setting it up in a way that your account may
>> run "poweroff" without having to authenticate first.  In that case,
>> you need to use
>> sleep 10 && sudo poweroff
>> inside the brackets in the above script.
>> (Note that I haven't tested this, but this is how it should work)
>>
>> The sleep 10 && poweroff tells your server to wait 10 seconds before
>> it starts powering down.  The brackets and the ampersand cause the job
>> to run in the background.  The disown tells your server to keep
>> executing the backgrounded task even if the session disconnects.  The
>> x2goterminate-session is basically the suicide command for your
>> running X2Go session.
>>
>> - -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)
>>
>> iQEcBAEBAgAGBQJUtrX5AAoJEG7d9BjNvlEZzFYIAI/tQr3s+E5p282MPpGw+PgG
>> gFNEDtdd77hANc+ESjmFMS0jIv3aSp8zUUh2jC0IvcCp6uh0N+B8zrU2rhdVi8qP
>> 4tS+GaA84IX9bFxhH27No9igIkrgSmD9y1UwENE/IywhlkQd+pcJumSOXoKw+RxK
>> NnXHZaVE8oow8Uw3G2jh0tfnjwE8wSR4pCte3k0ZTfFoT2WXxOmM6wwB7EyDGTqY
>> zO2oblaHdUN+XVppoEOcMFhtE1R1geDyPzU99Gl1cujrazE1mOQnziv88M84eVw4
>> +hirTPqHwbBIdBTtHN8Wu9crsibbkWel0Zv54eEkypDWia4nyXKJhiT4yfAOvFY=
>> =E/MW
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> x2go-user mailing list
>> x2go-user at lists.x2go.org
>> http://lists.x2go.org/listinfo/x2go-user
>

-- 
Peter Brodsky
Principal Engineer
Applied Physics Laboratory, University of Washington
1013 NE 40th St
Seattle, WA  98105
brodsky at apl.washington.edu
206.543.4216