Hi there, Is there a simple command line command to terminate the X2Go session while being on the remote server? So, the aim is to be able to terminate the session via the command line on the server, not on the client.
Thanks
On Thu, Jan 16, 2020 at 3:33 AM Bob Harold <bx2go@halfgoat.com> wrote:
That would be stopping whatever main process you started. In my case, I use "single command" - "xterm", and simply exiting the main xterm closes the session.
Yes, and that's just how it works. Either kill the x2goagent or initiate a shutdown of your Desktop Environment (or xterm in your case).
Uli
Greetings.
On 15/01/2020 19.13, Alexanderstr Miete wrote:
On the server, you can run x2golistsessions to get a list of active sessions. Then run x2goterminate-session, passing as the argument the ID of the session you want to terminate.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
Am 16.01.20 um 10:48 schrieb Tristan Miller:
When run from inside the session that you want to terminate, there is no need to dig for the session ID first. Just run x2goterminate-session without any parameters, and *poof*, your session is gone.
-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
On 16/01/2020 12.29, Stefan Baur wrote:
Sure, but it wasn't clear to me whether the OP was asking about being physically present on the remote server, or connected to it only via an X2Go client. (He asks only if there is a command to "terminate the X2Go session while being on the remote server".)
Maybe he has the same use case as me: at work I often make an X2Go connection from my office computer to my home computer. Sometimes I forget to terminate the connection before I come home from work, so I need to do it using x2goterminate-session on the "remote" server once I get home.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
Am 16.01.20 um 15:19 schrieb Tristan Miller:
Still worth pointing out that there are cases where you don't need to jump through multiple hoops.
That sounds wrong. You can remote-suspend a session between a client A and a server from another client B you're logged on to, and resume it from there. No need to terminate the 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
Greetings.
On Fri, 17 Jan 2020 15:46:15 +0100, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Suspending doesn't help when I want to locally run a program on the server (like my mail client or web browser) that permits only one instance at a time, and the X2Go session is already running such an instance. Or is there some way of moving a program from an X2Go session to the local display? (If there is, I expect it's not going to be any easier than manually killing the application, or simply terminating the entire X2Go session, and then restarting the program locally.)
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
On Fri, Jan 17, 2020 at 4:08 PM Tristan Miller <psychonaut@nothingisreal.com> wrote:
Am I getting something wrong here? You have an X2go session where program X is running and you need to run program X again which is not possible because it is running within the x2go session. So instead of connecting to the session and continuing to use the running instance of program X you kill the whole session and start a new one where you again start programX? Why?
Reconnecting to running sessions is one of the core purposes of X2go (or NX).
Uli
Am 17.01.20 um 16:08 schrieb Tristan Miller:
So why don't you start X2GoClient on the local screen and connect to 127.0.0.1 (or ::1, if you fancy IPv6) to resume your session?
Especially when using X2Go's published application mode instead of a full desktop environment, this should feel like it's running locally in the first place.
-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
Greetings.
On Fri, 17 Jan 2020 16:52:52 +0100, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
For the same reason I mentioned previously: because I need to run programs that allow only one concurrent instance. Consider what happens when I am running my web browser locally on my X2Go server, and then locally reconnect to a local X2Go session that is running my e-mail client. If I click on a hyperlink in an e-mail message, it will try (and fail) to launch a new instance of my web browser. As far as I know, the only solutions are to kill the local web browser and relaunch it within the X2Go session, or else kill the e-mail client and relaunch it locally. I usually just kill the entire X2Go session, since it's rare that the session is running anything other than the e-mail client.
If you know of a better way of dealing with this, I'd be happy to hear about it.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
Am 17.01.20 um 18:33 schrieb Tristan Miller:
So why don't you start X2GoClient on the local screen and connect to 127.0.0.1 (or ::1, if you fancy IPv6) to resume your session?
If you know of a better way of dealing with this, I'd be happy to hear about it.
"You're holding it wrong."
Like I said, run X2GoClient in Published Application Mode, and make it a habit to *always* use the "critical"/interconnected Apps via X2Go, no matter if you're coming from remote or not. You can run Browser and Mail Client remotely, then suspend, then resume them locally (using the X2Go connection to 127.0.0.1/::1), and they'll always behave like a local application.
Or, if you want/need a full remote desktop, set your local machine's desktop to a very minimal one, say, OpenBox spawning X2GoClient in fullscreen, then use X2GoClient with the connection to localhost to access your "real" desktop environment (MATE, XFCE, LXDE, whatever).
-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
Greetings.
On Fri, 17 Jan 2020 22:43:07 +0100, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
The problem with this approach is that these days a web browser is interconnected to just about everything. There's probably half a dozen applications I regularly use that sometimes or often present me with hyperlinks that open in an external web browser. So if I'm going to run my web browser in X2Go, then I have to run almost everything else in X2Go. Which brings me to your next point...
I don't want or need a full desktop as I prefer to run remote applications seamlessly on the client desktop. I'm often copying and pasting between remote and local applications, moving them between different screens and virtual desktops, etc. Having all the remote applications displayed in one window will unreasonably constrain my workflows.
But even if this weren't a concern of mine, I still couldn't do this because there are so many applications I run that don't run very well, or at all, under X2Go. Last I checked, Konsole ran terribly slowly, and Gnome-Terminal didn't run at all. Emacs crashes regularly unless I use an obscure and complicated workaround. (I've since automated this, but I don't relish the thought of having to go through all that troubleshooting again for some future misbehaving application.) KMyMoney crashes as soon as it's launched due to some GLX compatibility issue.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
On Sat, Jan 18, 2020 at 2:21 PM Tristan Miller <psychonaut@nothingisreal.com> wrote:
That is exactly the reason why I am working with rootless (=seamless) nx connections.
Please don't get us wrong: we appreciate anyone using x2go. We just want to help. Having to kill a session is something we want to avoid, that's why we have x2go!
Some tips: Konsole: set QT_GRAPHICSSYSTEM=native and switch to Xlib rendering in KDE. I am using it daily this way! Gnome-Terminal: I am not using this, so probably connected to GLX emacs: I am not aware of any crashing issues althought I am using it daily. Can you provide any more details? GLX: are you aware of this workaround?: https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround
Uli
Dear Ulrich,
On Sat, 18 Jan 2020 15:48:38 +0100, Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
By "switch to Xlib rendering in KDE", do you mean configuring KDE on the remote host to use XRender instead of OpenGL? If so, this workaround does nothing for me.
Gnome-Terminal: I am not using this, so probably connected to GLX
I doubt it; it doesn't print any console errors about GLX.
emacs: I am not aware of any crashing issues althought I am using it daily. Can you provide any more details?
The problem and workaround are described in the "Emacs crashes on start" thread on the X2Go-User list. See for example here: <https://lists.x2go.org/pipermail/x2go-user/2017-September/004524.html>
GLX: are you aware of this workaround?: https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround
Yes. Those instructions are out of date (Mesa wants to be compiled with meson, not scons). I tried adapting them and was able to compile the libraries, but after adding their location to LD_LIBRARY_PATH, glxinfo still reports the version to be 1.2. However, quite possibly I've done something wrong with the build. I can provide further information here or on X2go-User if you're interested.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
On Thu, Jan 23, 2020 at 1:07 PM Tristan Miller <psychonaut@nothingisreal.com> wrote:
Yes, there's a config option kde settings (Desktop effects/Advanced). You should set the compositign type to "Xrender" and the Qt graphics system to native. Sometimes KDE does not accept changing the values or changes them back at next start. In that case you have to set them manually in the config file (without kde running):
/.kde/share/config/kwinrc in dection [Compositing] add/adapt to Backend=XRender.
What? I had the impression that this bug is long gone! What emacs/distribution and what NX version are you using where this error shows up?
I have done it successfully ~1 year ago using this document: https://mesa3d.org/llvmpipe.html
Uli
Dear Uli,
On Thu, 23 Jan 2020 13:45:46 +0100, Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
Well, that's what I had been doing (though I didn't need to manually edit the config file as KDE remembered the setting). Konsole rendering is as slow as ever.
That's news to me; none of the myriad bug reports filed about this issue have ever been marked as resolved:
https://bugzilla.gnome.org/show_bug.cgi?id=85715 https://gitlab.gnome.org/GNOME/gtk/issues/221 https://bugzilla.redhat.com/show_bug.cgi?id=1349412 https://bugzilla.suse.com/show_bug.cgi?id=1007912
I tried running Emacs over X2Go just now, without the EMACS_TOOLKIT=x11 workaround, and so far it seems to work fine. So I guess you are right that the bug has since been fixed. If so, maybe you are the only one who ever noticed this and everyone else, like me, is continuing to use one of the workarounds. :)
Those instructions don't work for me. Specifically, they fail when meson is invoked to build the library:
$ meson -D glx=gallium-xlib -D gallium-drivers=swrast The Meson build system Version: 0.51.2 Source dir: /home/psy/src/mesa-19.3.2 Build dir: /home/psy/src/mesa-19.3.2/build Build type: native build Program python found: YES (/usr/bin/python) Project name: mesa Project version: 19.3.2 Appending CFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' Appending CFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' C compiler for the host machine: ccache cc (gcc 9.2.1 "cc (SUSE Linux) 9.2.1 20200109 [gcc-9-branch revision 280039]") Appending CPPFLAGS from environment: '-march=native' C++ compiler for the host machine: ccache c++ (gcc 9.2.1 "c++ (SUSE Linux) 9.2.1 20200109 [gcc-9-branch revision 280039]") Build machine cpu family: x86_64 Build machine cpu: x86_64
meson.build:403:6: ERROR: Problem encountered: gallium-xlib conflicts with any dri driver
I tried forcing the build using scons instead, and the library gets built, but once again, putting the library directory in LD_LIBRARY_PATH still results in glxinfo reporting GLX version 1.2.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
I have updated the instructions at https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround
Works for me ;-)
Uli
On Thu, Jan 23, 2020 at 3:37 PM Ulrich Sibiller <uli42@gmx.de> wrote:
Dear Uli,
On Thu, 23 Jan 2020 19:40:05 +0100, Ulrich Sibiller <uli42@gmx.de> wrote:
Thanks; working fine for me as well now!
If you'd like, I can contribute instructions for openSUSE as well. Perhaps I could be given an account on the wiki?
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
Greetings.
On Fri, 24 Jan 2020 09:23:42 +0100, Tristan Miller <psychonaut@nothingisreal.com> wrote:
By the way, your instructions suggest using a wrapper script that sets LD_LIBRARY_PATH when invoking GLX applications. Is there any reason that I can't just export LD_LIBRARY_PATH globally in my X2Go sessions? That is, is there any danger/disadvantage to using Mesa's libGL when running non-GLX applications over X2Go? I ask because just setting LD_LIBRARY_PATH in my .bashrc (within an if block that checks for $X2GO_AGENT_PID or $X2GO_SESSION) will be easier than remembering to manually invoke a wrapper for GLX applications.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
On Fri, Jan 24, 2020 at 9:50 AM Tristan Miller <psychonaut@nothingisreal.com> wrote:
Do as you like. ;-) Generally speaking I don't like setting LD_LIBRARY_PATH (or even LD_PRELOAD) globally (t.i. session-wide) because I have seen many applications that fiddle with the LD_LIBRARY_PATH themselves and are not prepared for the variable already being set. So they either break that functionality or fail with weird errors. If you explicitly called such an application with a wrapper you are aware that you did just that and can easily try the application without the wrapper. Global variables tend to be forgotten...
Uli
On Fri, Jan 24, 2020 at 9:24 AM Tristan Miller <psychonaut@nothingisreal.com> wrote:
good!
If you'd like, I can contribute instructions for openSUSE as well. Perhaps I could be given an account on the wiki?
Of course. Unfortunately I do not have permissions to accomplish that. Stefan?
Uli
Am 24.01.20 um 09:49 schrieb Ulrich Sibiller:
Me neither, I think, but Mihai should be able to do that. Tagging him here.
-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
Am 16.01.20 um 14:33 schrieb Paul Borowicz:
Try 'pkill -u username'
That's what I usually do.
Yes, fire a shotgun at all 4 tires simultaneously and plug a potato into the exhaust pipe just for good measure when you want the car to stop; simply stepping on the brake pedal instead is so lame ...
-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
-
Alexanderstr Miete -
Bob Harold -
Paul Borowicz -
Stefan Baur -
Tristan Miller -
Ulrich Sibiller -
Ulrich Sibiller