Bug #1724790 “Can't see the remote desktop” : Bugs : nxcomp package : Ubuntu

Revision history for this message

Jean Tinguely Awais (jean.tinguely) wrote on 2017-10-19:

#1

Dependencies.txt Edit (5.5 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (963 bytes, text/plain; charset="utf-8")
ProcEnviron.txt Edit (328 bytes, text/plain; charset="utf-8")

Revision history for this message

Jean Tinguely Awais (jean.tinguely) wrote on 2017-10-19:

#2

Download full text (28.3 KiB)

See IRC freenode #x2go on 2017/09/19

[09:08] == jta_1972 [b2c10097@gateway/web/freenode/ip.178.193.0.151] has joined #x2go
[09:15] <jta_1972> Hello,
[09:15] <jta_1972> I have a problem.
[09:15] <jta_1972> The log of x2go are here : https://dpaste.de/VCVT
[09:16] <mbecroft> Ionic: I built the latest release, 3.5.99.10
[09:16] <jta_1972> Line 157: I can't understand why I can't reach the Xdisplay.
[09:17] <mbecroft> It's working fine, and I've cleaned up the packaging so it doesn't do silly things, like what was causing the cwd to get set weirdly
[09:18] <jta_1972> I delete .xauthority, reboot : nothing works!
[09:18] <mbecroft> I had a look a the x2goserver ebuild as well, since actually that seems broken in gentoo currently, but that one is rather long and needs a bit more effort to untangle what's being done
[09:18] <jta_1972> Must I reinstall a package?
[09:20] <mbecroft> Ionic: so, I'll stick with this for now as it's working and I am on an up-to-date 3.5 release, and if it does crash it actually writes a core dump now, so I can at least debug it, if the rare crash bug(s) I experience should reoccur. When I feel like spending a weekend on it, I guess I'll try and sort out 3.6 and newer x2goserver
[09:20] <uli421> mbecroft: 3.5.99.x is actually the 3.6-release beta.
[09:21] <mbecroft> Oh
[09:21] <mbecroft> Well, then, it basically works fine
[09:21] <mbecroft> I didn't even need to upgrade x2goserver like you suggested I might
[09:22] <mbecroft> The current maintainer said he is very busy and would appreciate some help. So I'll at least send him the 3.5.99.10 ebuild for possible inclusion (in 'beta' status) for those who wish to use it
[09:23] <uli421> jta_1972: "Error: Error 2 'No such file or directory' checking '/tmp/user/1003/.X11-unix'." That's your problem.
[09:24] <mbecroft> I've removed years of crap from the ebuild, which means it is much simpler and installs everyting in the expected way, but could possibly mean it is no longer compatible with some other packages that use it, like freenx and qtnx. I haven't tested that, I'm just guessing.
[09:25] <jta_1972> Thank your uli421. How can I solve this problem? Must I reinstall X11?
[09:25] <mbecroft> Ionic: Also, I'm just about to actually test this, but it appears extra nxagent options can be specified in /etc/x2go/x2goagent.options - hopefully no need to hack the x2gostartagent script
[09:26] <uli421> mbecroft: you should upgrade the server as only new version know about the new nx-libs. Older x2goservers will not setup the environment correctly
[09:26] <uli421> jta_1972: it is on you client side. Check /var/log/Xorg.0.log.
[09:26] <mbecroft> uli421: Well this is what was told to me, but it is actually working fine as far as I can see. What specifically might I expect to not be working right?
[09:27] <mbecroft> I did have a look at x2goserver, but the ebuilt is way complex and failing in a non-obvious way (even on the *current* version) so I have deferred that for now
[09:28] <uli421> mbecroft: xinerama will not work
[09:28] <mbecroft> I don't believe I use Xinerama, so if that's all, it's no loss to me for now
[09:29] <uli421> mbecroft: you can check on the server side: ps waux | ...

See IRC freenode #x2go on 2017/09/19

[09:08] == jta_1972 [b2c10097@gateway/web/freenode/ip.178.193.0.151] has joined #x2go
[09:15] <jta_1972> Hello,
[09:15] <jta_1972>  I have a problem.
[09:15] <jta_1972> The log of x2go are here : https://dpaste.de/VCVT
[09:16] <mbecroft> Ionic: I built the latest release, 3.5.99.10
[09:16] <jta_1972> Line 157: I can't understand why I can't reach the Xdisplay.
[09:17] <mbecroft> It's working fine, and I've cleaned up the packaging so it doesn't do silly things, like what was causing the cwd to get set weirdly
[09:18] <jta_1972> I delete .xauthority, reboot : nothing works!
[09:18] <mbecroft> I had a look a the x2goserver ebuild as well, since actually that seems broken in gentoo currently, but that one is rather long and needs a bit more effort to untangle what's being done
[09:18] <jta_1972> Must I reinstall a package?
[09:20] <mbecroft> Ionic: so, I'll stick with this for now as it's working and I am on an up-to-date 3.5 release, and if it does crash it actually writes a core dump now, so I can at least debug it, if the rare crash bug(s) I experience should reoccur. When I feel like spending a weekend on it, I guess I'll try and sort out 3.6 and newer x2goserver
[09:20] <uli421> mbecroft: 3.5.99.x is actually the 3.6-release beta.
[09:21] <mbecroft> Oh
[09:21] <mbecroft> Well, then, it basically works fine
[09:21] <mbecroft> I didn't even need to upgrade x2goserver like you suggested I might
[09:22] <mbecroft> The current maintainer said he is very busy and would appreciate some help. So I'll at least send him the 3.5.99.10 ebuild for possible inclusion (in 'beta' status) for those who wish to use it
[09:23] <uli421> jta_1972: "Error: Error 2 'No such file or directory' checking '/tmp/user/1003/.X11-unix'." That's your problem.
[09:24] <mbecroft> I've removed years of crap from the ebuild, which means it is much simpler and installs everyting in the expected way, but could possibly mean it is no longer compatible with some other packages that use it, like freenx and qtnx. I haven't tested that, I'm just guessing.
[09:25] <jta_1972> Thank your uli421. How can I solve this problem? Must I reinstall X11?
[09:25] <mbecroft> Ionic: Also, I'm just about to actually test this, but it appears extra nxagent options can be specified in /etc/x2go/x2goagent.options - hopefully no need to hack the x2gostartagent script
[09:26] <uli421> mbecroft: you should upgrade the server as only new version know about the new nx-libs. Older x2goservers will not setup the environment correctly
[09:26] <uli421> jta_1972: it is on you client side. Check /var/log/Xorg.0.log.
[09:26] <mbecroft> uli421: Well this is what was told to me, but it is actually working fine as far as I can see. What specifically might I expect to not be working right?
[09:27] <mbecroft> I did have a look at x2goserver, but the ebuilt is way complex and failing in a non-obvious way (even on the *current* version) so I have deferred that for now
[09:28] <uli421> mbecroft: xinerama will not work
[09:28] <mbecroft> I don't believe I use Xinerama, so if that's all, it's no loss to me for now
[09:29] <uli421> mbecroft: you can check on the server side: ps waux | grep x2goagent -> get pid -> grep -i xinerama /proc/PID/maps -> should NOT use the xinerama lib of NX but from the system.
[09:32] <uli421> jta_1972: I think even a simple xterm or xclock will not work for your client in the current setup
[09:33] <mbecroft> uli421: let me check
[09:34] <mbecroft> uli421: It is using the system-supplied libXinerama
[09:35] <mbecroft> I don't believe there is any NX-supplied libXinerama; at least, if there is, my ebuild does not install it
[09:35] <mbecroft> Everything I've tested seems to be absolutely fine, except the font path default being bad. The was the only thing I've had to fix (by setting it in my .xsession)
[09:35] <jta_1972> uli421: thank your. The X0.lor are here https://dpaste.de/axF2. I don't see nothing strange.
[09:36] <jta_1972> uli421: sorry Xorg.0.log.
[09:37] <mbecroft> uli421: Specifically, it's using libXinerama from x11-libs/libXinerama, which is part of xorg that is already installed on my system
[09:37] <mbecroft> Is there anything else I should check?
[09:40] <uli421> jta_1972: sudo lsof -p $(pidof Xorg) | grep unix should show you where your X11-socket is.
[09:41] <uli421> mbecroft: that's good. Please check this: strings /proc/PID/environ | grep LD_
[09:42] <jta_1972> uli421: Thank you. My X11 socket is there: /tmp/.X11-unix
[09:43] <jta_1972> uli421: How can I bind x2go to the socket?
[09:44] <mbecroft> uli421: There is no output (nothing in the environment beginning with LD_)
[09:46] <jta_1972> uli421: The output of sudo lsof -p ... is here: https://dpaste.de/gbGC
[09:51] <mbecroft> Hmm, ok so I need to get my head around "nx/nx" options vs. direct arguments to the nxagent command...maybe I do have to hack x2gostartagent to set those after all.
[09:53] <uli421> jta_1972: I don't know why x2go is trying another socket. Please paste echo $DISPLAY and xauth list $DISPLAY
[09:55] == yppo [~1445fc@h-2-106.A230.priv.bahnhof.se] has left #x2go []
[09:56] <jta_1972> uli421: there the output of the instructions.
[09:56] <jta_1972> jean@sibold-desktop:/$ echo $DISPLAY :0 jean@sibold-desktop:/$ xauth list $DISPLAY sibold-desktop/unix:0  MIT-MAGIC-COOKIE-1  9e2e15549e3b0ea58acd88576c61ca07
[09:56] == Shawn|i7-720QM [~shawn156@unaffiliated/shawn156] has quit [Read error: Connection reset by peer]
[09:56] <jta_1972> jean@sibold-desktop:/$ echo $DISPLAY :0
[09:57] <jta_1972> xauth list $DISPLAY = sibold-desktop/unix:0  MIT-MAGIC-COOKIE-1  9e2e15549e3b0ea58acd88576c61ca07
[09:57] <Ionic> mbecroft: oh but that's arctica?
[09:58] == Ryushin [chris@2001:470:4b:38f:777::8774] has joined #x2go
[09:58] <mbecroft> Ionic: sorry, what is?
[09:58] <Ionic> mbecroft: yes, but not these special options that go into the DISPLAY variable
[09:59] <Ionic> 3.5.99 is arctica
[09:59] <mbecroft> Yes, there doesn't appear to be any other project actively maintaining nx 3.5
[09:59] <mbecroft> although apparently 3.5.99 is actually 3.6 anyway
[09:59] <Ionic> yeah, 3.6 will be released at some point from the 3.5.99 codebae
[09:59] <Ionic> codebase
[10:00] <mbecroft> So the release tarballs of 3.5 are actually from the 3.6.x branch, or?
[10:00] <mbecroft> *3.5.99
[10:00] <Ionic> yes, of the arctica project
[10:01] <Ionic> not from our X2Go repo
[10:01] <mbecroft> Ok
[10:01] <uli421> jta_1972: output looks ok. Hmmm
[10:02] <mbecroft> Thanks for clarifying. It's not immediately obvious to an outsider than 3.5.99 is actually 3.6! I was avoiding 3.6 because everyone said it will not be compatible with my existing x2goserver, and has major changes that will require changes to how it is built etc... but actually it was simpler to build and it works perfectly as far as I can tell so far!
[10:02] <Ionic> the current x2go nx-libs use a self-provided xinerama library
[10:02] <Ionic> arctica doesn't any longer
[10:03] <mbecroft> uli421 mentioned this. I verified that nxagent is indeed linked with the libXinerama separately installed on my system from xorg
[10:04] <Ionic> yeah :)
[10:04] <uli421> jta_1972: what does env | grep TMP show?
[10:04] <mbecroft> Now I'm just seeing how this options file works, and the manual says you can even change the options at runtime, which sounds fantastic! But it it is not obvious to me how to tell nxagent that the options file should be re-read.
[10:04] <uli421> mbecroft: the re-read happens only on reconnect.
[10:05] <mbecroft> uli421: Ah, thanks. I will test it :)
[10:05] <uli421> mbecroft: should probably be mentioned in the manpage
[10:05] <mbecroft> Oh wait
[10:05] <Ionic> but you can't overwrite the options file easily with x2go
[10:05] <mbecroft> Does that file get modified by x2go itself during reconnect (clobbering any manual changes I might make)?
[10:05] <Ionic> since the client will do it on every reconnect
[10:05] == atomic1 [~atomic@saturn.2f30.org] has joined #x2go
[10:05] <Ionic> yes
[10:06] <mbecroft> Ah
[10:06] <mbecroft> Perhaps an area for future improvement then
[10:06] <Ionic> which is why I recommend editing x2gostartagent
[10:06] <mbecroft> right
[10:06] <uli421> mbecroft: I have opened an according issue: https://github.com/ArcticaProject/nx-libs/issues/535
[10:06] <mbecroft> It looks easy to insert some additional options there
[10:07] <atomic1> i'm using SCL devtoolset-6 but when connected via x2go and i type "scl enable devtoolset-6 bash" i dont have the correct PATH available
[10:07] <mbecroft> uli421: awesome. Everyone seems to be on the same page on this
[10:07] <Ionic> atomic1: known issue, will be fixed whenever I release a new x2goclient release
[10:08] <atomic1> Ionic: oh ok
[10:08] <Ionic> we override PATH in a hard way currently
[10:08] <atomic1> argh
[10:08] <Ionic> but you can always reset it manually in a started session
[10:08] <mbecroft> I have a cunning plan...
[10:09] <Ionic> uhoh...
[10:09] <jta_1972> uli421: It's wrong in the environment!
[10:09] <jta_1972> TMPDIR=/tmp/user/1003
[10:09] <mbecroft> Ionic: when reconnecting, is it specifically the x2gostartagent script which rewrites the options file, or some other script?
[10:09] <atomic1> Ionic: the script doesn't really work in any way. even starting it after starting a new terminal doesn't work
[10:09] <jta_1972> TMP=/tmp/user/1003
[10:09] <Ionic> jta_1972: probably set by systemd
[10:09] <Ionic> mbecroft: x2gostartagent just spawns it the first time around
[10:10] <mbecroft> Ionic: what rewrites the options on reconnect?
[10:10] <Ionic> on resume, x2goresume-session modifies it again
[10:10] <mbecroft> Thanks
[10:11] <uli421> Ionic: on my Cetnos7 office machine (where I am _not_ root) we are using an own openssh server package (which is not delivered as RPM). Therefor the machines do not have the openssh-server package installed. I now asked my colleagues to install x2goclient on the machine and we noticed that it pulls in openssh-server. Like it should. But unfortunately that package enable sshd automatically. So on the next reboot _that_ sshd was started and so
[10:11] <Ionic> but you don't really need to change it
[10:11] <jta_1972> Ionic: How to fix this?
[10:11] <mbecroft> Oh my gosh that's horrendous
[10:12] <uli421> jta_1972: not essentially wrong, but nxproxy is picking it up. And that's a bug, AFAIKS!
[10:12] <Ionic> mbecroft: just add the option in x2gostartagent and x2goresume-session should leave unknown values in there
[10:12] <Ionic> no need to also edit x2goresume-session
[10:12] <mbecroft> I see
[10:12] <Ionic> uli421: it is a bug if the X server socket is not in there
[10:12] <Ionic> err
[10:12] <Ionic> is not *not* a bug, if...
[10:13] <uli421> Ionic: no, its not. At that place $TMPDIR has to be ignored, as /tmp/.X11-unix is hardcoded in libX11 and the server
[10:13] <Ionic> uli421:
[10:13] <Ionic> uli421: "So on the next reboot _that_ sshd was started and so"
[10:13] <uli421> Ionic: too many topics at once... ;-)
[10:13] <Ionic> (message was truncated after that)
[10:13] <uli421> and so out own sshd could not run. What do you think: shouldn't we ensure that the service does not get activated by an x2goclient install, even if the package does so by default?
[10:14] <Ionic> no can do that
[10:14] <Ionic> RHEL/Fedora/CentOS have a list of systemd services that should be started automatically and there's no way we could override it in X2Go
[10:15] <uli421> jta_1972: as a workaround: Does it work if you set TMPDIR to /tmp before starting x2goclient?
[10:16] <uli421> Ionic: That's a pity. Away from our specific problem: If someone has not installed openssh-server and install x2goclient he will get a running sshd without ever noticing.
[10:17] <Ionic> yeah, but I'm afraid there's nothing we can do about that
[10:17] <jta_1972> uli421: Don't work! See this https://dpaste.de/VfwP
[10:18] <Ionic> interesting, still using the other tmpdir
[10:19] <jta_1972> uli421: see line 105
[10:19] <jta_1972> uli421: sorry line 104
[10:20] <Ionic> what does /home/jean/.x2go/S-odoo-50-1508336076_stDXFCE_dp24/options contain?
[10:20] <uli421> jta_1972: I see. Well, I suppose that TMPDIR variable is set by pam
[10:20] <Ionic> uli421: is PAM able to override the environment at will, even for new processes?
[10:21] <Ionic> without any previous login?
[10:21] <mbecroft> Nice, patched x2gostartagent and everything is working just how I like it
[10:21] <mbecroft> :)
[10:22] <jta_1972> Ionic: the content is under!
[10:22] <mbecroft> Interesting observation...:
[10:22] <jta_1972> nx/nx,root=/home/jean/.x2go,connect=localhost,cookie=d72745941c3e674512c3e8779ac5893a,port=47277,errors=/home/jean/.x2go/S-odoo-50-1508336076_stDXFCE_dp24/sessions:50
[10:22] <mbecroft> I sometimes use x11vnc to access my nxagent session while it is in suspended sate
[10:22] <Ionic> ah
[10:22] <mbecroft> *state
[10:22] <Ionic> mbecroft: it'll be slow, right?
[10:22] <mbecroft> That's the interesting part
[10:23] <mbecroft> Right now I'm just running glxgears within nxagent as a sort of test
[10:23] <Ionic> glxgears isn't a good test, but go on...
[10:23] <Ionic> (it should be blazingly fast if nothing is connected to the display)
[10:23] <Ionic> jta_1972: looks fine, mm
[10:23] <mbecroft> It is approx 5x faster with nxagent suspended and displaying via x11vnc, than when not using x11vnc and using nx
[10:24] <mbecroft> Of course it will be fast while suspended, but x11vnc is able to deliver 5x better performance *for this special case* than nx/x2go
[10:24] <uli421> Ionic: I don't know. But x-sessions a re special anyway
[10:25] <Ionic> jta_1972: just as a test, if you call "bash" and echo $TMPDIR $TMP, what values are you getting? exit with "exit" afterwards
[10:25] <Ionic> uli421: not really that special... since x2goclient is the parent, the environment should be passed on
[10:26] <mbecroft> This sets a substantial lower bound on the room for improvement in nx (for the glxgears use case)
[10:26] <uli421> Ionic: x2goclient has a getXDisplay() method, but only for windows and osX, otherwise it seems to use some default. Which might be buggy in qt.
[10:26] <Ionic> mbecroft: not really. you'll get the same behavior on local sessions when running glxgears and switching to a VT for instance
[10:26] <jta_1972> Ionic: The environment is not changed : /tmp/user/1003 /tmp/user/1003 !
[10:26] <Ionic> (if you disable vsync)
[10:26] <uli421> Ionic: yes, but I am talkign about those xsession files in /etc the the distro brings into the game.
[10:27] <Ionic> uli421: nope, see what we just tested. he exports TMPDIR and TMP, calls bash and all of a sudden these variables are different again
[10:27] <Ionic> but that's only called once at session startup
[10:27] <mbecroft> Ionic: No, this is with x11vnc displaying glxgears to my screen
[10:27] <Ionic> something must be injecting TMPDIR and TMP into new processes directly
[10:27] <mbecroft> over the same WAN link
[10:28] <uli421> Ionic: the bashrc?
[10:28] <Ionic> hmm, or another shell startup script, yeah
[10:28] <jta_1972> uli421: Should work. I test.
[10:28] <Ionic> given that QProcess also launches processes in a new shell, that makes sense
[10:30] <Ionic> mbecroft: yeah, but the point is that nxagent might not even render all frames if viewed via x11vnc
[10:30] <mbecroft> So out of morbid curiosity, I also tested google-chrome, which has this horrendous attribute of copying the *entire* contents of its window as a pixmap from the client into the X server on *every* change to the page. Which is stupid o chrome and one of the reasons I don't use chrome if I can avoid it but... Approx performance on this test, under x11vnc vs nx, is also in x11vnc's favour, though not nearly to the same
[10:30] <mbecroft>  degree.
[10:30] <mbecroft> Ionic: that is true
[10:30] <Ionic> while when you are connected to it, it must carry out all operations sequentially
[10:31] <mbecroft> But does open up whole new realms for enhancing nx in the future
[10:31] <mbecroft> Which is to decouple that
[10:31] <mbecroft> Not trivial by any means, I know
[10:31] <jta_1972> uli421: I test it! Does not work. See https://dpaste.de/CvQy
[10:32] <uli421> mbecroft: which is basically how NomachineNX is working nowadays
[10:32] <mbecroft> But possibly one of the places we need to go, if we want to get some major improvements to certain types of workloads
[10:32] <jta_1972> uli421: I eport the new TMP and TMPDIR in .bashrc.
[10:32] <Ionic> uh, wow
[10:32] <Ionic> and bash is your default shell?
[10:32] <mbecroft> uli421: what is up with Nomachine these days? I basically forgot about nomachine after they closed-sourced NX 4.
[10:32] <Ionic> although, no, wait, .bashrc is not executed for non-interactive shells
[10:33] <Ionic> do you have a ~/.profile or ~/.bash_profile file?
[10:33] <mbecroft> No thanks for the numerous patches I contributed over several years to NX 3, and where I even *paid them for support* just to have them mainline my fixes for major bugs
[10:33] <uli421> mbecroft: the old nx x11 style is called legacy. The current version does delta compression like everyone else does. + virtualgl
[10:34] <jta_1972> Ionic: echo $SHELL ==> /bin/bash Yes, it's my default shell.
[10:34] <uli421> mbecroft: you actually sent in patches? Nice! I remember the main developer quitting all mailing lists because nobody contributed.
[10:35] <mbecroft> uli421: Yes, a number of patches including for major bugs
[10:35] <uli421> mbecroft: I have not seen that mentioned in the changelogs
[10:35] <Ionic> jta_1972: what about ~/.profile and ~/.bash_profile? :)
[10:35] <mbecroft> uli421: Knowing nomachine, they probably stripped my name from anyting I controbuted
[10:35] == tru_tru [~tru@atsukau.bis.pasteur.fr] has joined #x2go
[10:37] <mbecroft> uli421: So Nomachine NX 4 still transmits a delta-compressed X11 command stream, combined in some way with virtualgl-style graphics compression...? Or are they transliterating X11 drawing commands into a newly-designed form for compression/transmission; or are you saying that they are now no better than VMware, vnc etc. which just sends compressed pixmaps of screen regions?
[10:38] <jta_1972> Ionic: I have .profile
[10:38] <Ionic> mbecroft: they are doing delta compression now, not sequential execution of commands
[10:38] <Ionic> jta_1972: try exporting these variables there please
[10:38] <mbecroft> Ionic: delta comprsesion of pixmaps or of the X11 server state?
[10:39] <Ionic> I guess they batch operations, send them over and execute them as such as well
[10:39] <mbecroft> I see
[10:39] <mbecroft> A combination of techniques will be needed to get optimal performance for all workloads
[10:39] <uli421> mbecroft: I don't know exactly, I have not looked deeply into it. A colleague of mine mentioned that the old nx protocol is called  legacy and not enabled by default anymore. And I have seen virtualgl is involved. And yes, delta compression of the images + some H.264 (or 265?) compression, too.
[10:39] <mbecroft> I can't believe how shitty VMware VDI is and yet they take over the market
[10:40] <jta_1972> Ionic: I export the 2 variables in .profile, at the end of the file.
[10:40] <uli421> mbecroft: if windows was using X11 the situation would be different...
[10:40] <Ionic> no matter how shitty a solution is, if a company offers support other companies will jump on the wagon
[10:41] <Ionic> jta_1972: and? still no dice?
[10:41] <uli421> "Nobody has ever been fired for buying IBM" - that's how it works.
[10:42] <mbecroft> If NX is actually batching compressed X11 command streams and doing state sync of X11 objects, in combination with treating the display region as a pixmap with intra and inter-frame compression for transport, then they are onto something. I'd like to know if they really are that good. I someone think maybe not.
[10:42] <mbecroft> brb
[10:42] <uli421> mbecroft: there's a trial version of NX5, just have alook.
[10:43] <jta_1972> Ionic: I open  a new terminal an launch x2goclient. Same error : https://dpaste.de/Xcc4
[10:43] <uli421> mbecroft: btw: you might be interested in latest effort: upgrading opengl in nx: https://git.io/vdQNp
[10:43] <uli421> s/in/in my/
[10:43] == Statler [~Georg@p579FEFB4.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
[10:44] <Ionic> okay... my best guess is that something is injecting these variables directly
[10:44] <uli421> mbecroft: you seem to know a lot of NX internals. Aren't you interested in helping in pushing nx-libs forward? See https://github.com/ArcticaProject/nx-libs
[10:46] <Ionic> he actually already sponsored some work...
[10:48] <uli421> Ionic: sorry, I do not have an overview over sponsoring
[10:48] <jta_1972> Ionic: Thank your for your help.
[10:49] <Ionic> jta_1972: well, not really successful help
[10:49] <uli421> Ionic: on my Ubuntu 16.04 the socket path is hardcoded: strings /usr/lib/x86_64-linux-gnu/libxcb.so | grep .X11
[10:49] <uli421> /tmp/.X11-unix/X
[10:49] <uli421> So I am wondering why these variables should matter at all!
[10:50] <Ionic> uli421: nxproxy doesn't use libxcb but libX11?
[10:51] <uli421> Ionic: yes, and libX11 is in turn using libxcb nowadays
[10:52] <uli421> and nxproxy does not have a reference to the socket.
[10:52] <Ionic> ah
[10:52] <Ionic> well I would expect it to honor TMPDIR
[10:53] <uli421> Ionic: I remember sunweaver implementing so code for per-session var directories that some distros are using. Maybe we have something similar here.
[10:54] <uli421> Ionic: I would _not_ expect it because TMPDIR is a user modifiable variable. The system must ensure that the X server and and any X client (that are both started totally independently from each other) agree about the value.
[10:54] <Ionic> yeah there was a fix for Fedora systems that use ephemeral tmpdirs but I don't remember in what component
[10:57] == es0thz [~Palat4@karel.tt.ee] has quit [Quit: Disconnecting from stoned server.]
[10:59] <jta_1972> uli421: Thank you too for your help.
[11:01] == es0thz [~Palat4@karel.tt.ee] has joined #x2go
[11:03] <uli421> jta_1972: you're welcome
[11:06] == Ryushin [chris@2001:470:4b:38f:777::8774] has quit [Ping timeout: 246 seconds]
[11:07] == Hybrid [~walid@195.200.167.70] has quit [Ping timeout: 248 seconds]
[11:08] <uli421> Ionic: have not found anything regarding ephemeral tmpdirs in the logs of arctica or x2goclient
[11:12] <Ionic> might have been in x2goserver
[11:13] <Ionic> can't find it either though
[11:15] <mbecroft> uli421: just catching up. Yes I am very interested
[11:15] <mbecroft> It is some while since I worked on internals, though
[11:16] <Ionic> nxproxy does use TMP though
[11:16] <Ionic> oh well, not quite "TMP" but "TEMP"
[11:19] <Ionic> and yep
[11:20] <Ionic> we set this path ourselves in nxcomp/src/Loop.cpp
[11:20] == Ryushin [chris@2001:470:4b:38f:777::8774] has joined #x2go
[11:20] <Ionic> using the curiously though, we're only checking NX_TEMP and TEMP
[11:21] <jta_1972> Ionic: I export TEMP=/tmp then the x display was starting.
[11:21] <jta_1972> Is this a bug?
[11:21] <Ionic> aaah
[11:21] <uli421> mbecroft: I'd be happy if someone could test OpenGL. My possibilities are limited
[11:22] <mbecroft> uli421: I have also been working with theUser2 on ideas around transport-layer improvements that could (a) provide better-than-TCP performance over WAN and mobile/LTE networks for existing service classes including TCP-like in-order derlivery (with selectable througput/latency trade-offs, some of which may permit advanced FEC techniques to remove retransmission delays) - key point being that existing services such a
[11:22] <mbecroft> s NX protocol benefit from this while the transport layer appears as it always has, so no upper-layer changes are needed to get some benefit (those types of networks are becoming increasingly commonn, so this is very important); and (b) provide a basis for some other techniques such as state-synchronisation, lossy delivery, eventual consistency an so forth, which enable upper layer protocols to do very clever things
[11:22] <mbecroft>  more easily
[11:22] <Ionic> right, the nxproxy wrapper script has a comment  about pam_tmpdir.so
[11:22] <Ionic> jta_1972: well TEMP and NX_TEMP override the default behavior
[11:23] <uli421> mbecroft: you mean something like mosh.org does?
[11:23] <jta_1972> Ionic: Well indeed I do a apt-get purge and the apt-get install of x2goclient.
[11:23] <Ionic> but no, still not a bug
[11:23] <mbecroft> uli421: Some of the techniques they use would apply, but also even more powerful ones
[11:24] <Ionic> nxproxy checks NX_TEMP first, then TEMP and then defaults to /tmp
[11:24] <Ionic> what packages did you install and from what repository?
[11:24] <Ionic> dpkg -l | grep -i x2goclient and apt-cache show x2goclient
[11:24] <jta_1972> Ionic: for ubuntu 16.04.3 LTS
[11:24] <mbecroft> uli421: But yes, one class of techniques is basically what mosh does, but generalised
[11:25] <jta_1972> ii  x2goclient                                           4.0.5.1-1                                    amd64        X2Go Client application (Qt4)
[11:25] <Ionic> oh it's from the ubuntu repository itself then
[11:25] <Ionic> and also that's why it's so old
[11:25] <mbecroft> uli421: I happen to have some GPU programming experts in the building, so...
[11:26] <uli421> Ionic: Again: Clients use libX11 or libxcb and THAT decides where to lookup the socket. And they must use the same location where the server created the socket. So it MUST NOT depend on the TEMP variable. That's how X11 is working.
[11:26] <jta_1972> Package: x2goclient Priority: extra Section: universe/x11 Installed-Size: 2669 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Original-Maintainer: X2Go Packaging Team <pkg-x2go-devel@lists.alioth.debian.org> Architecture: amd64 Version: 4.0.5.1-1
[11:26] <mbecroft> uli421: If you tell me what you need around OpenGL I can maybe help
[11:26] <Ionic> uli421: no, not for nxproxy!
[11:26] <Ionic> that does it itself
[11:27] <uli421> Ionic: then it is a bug. The proxy is a an X client like everyone else, it must use the same techniques to access the local X server.
[11:27] <uli421> Ionic: AFAIK nxproxy is simply calling nxcomp.
[11:28] <Ionic> yes, nxcomp is the underlaying library
[11:28] <uli421> mbecroft: those transport-layer improvements sound interesting!
[11:28] <Ionic> uli421: nxproxy is a bit special because it must do cookie forwarding as well
[11:30] <mbecroft> What is sunweaver up to these days? Mainly nx 3.6 ?
[11:31] <uli421> mbecroft: regarding OpenGL: I have upgraded the GLX extension to support OpenGL 2.1. But I have not found a tool that an verify if that is working correctly. And I also had to make some  calls a no-op to make it compile, since the corresponding are not in the mesa code. So I do not know if it is working properly.
[11:31] <uli421> s/an/can/
[11:31] <Ionic> yep
[11:31] <uli421> s/corresponding/corresponding functions/
[11:31] <mbecroft> uli421: I see. I have people who can do that, I need to look a the budgeting for it however
[11:32] <Ionic> jta_1972: that doesn't make sense, nxproxy shouldn't use TEMPDIR/TMP at all
[11:32] <Ionic> err TMPDIR
[11:32] <mbecroft> uli421: Please remind me in a week or so if I haven't come back with something
[11:32] <uli421> mbecroft: thanks!
[11:32] <Ionic> unless...
[11:35] <Ionic> hm, looks like the ubuntu version isn't using a wrapper script
[11:35] <Ionic> but that shouldn't matter
[11:35] <Ionic> nope, no idea why it's behaving like that
[11:36] <Ionic> ubuntu didn't apply patches that would cause this as far as I can tell
[11:44] <jta_1972> Ionic: May be we can put a bug on launchpad.
[11:48] <uli421> $ TEMP=dummy strace /usr/local/nx/3.5.0/bin/nxproxy  -C :40
[11:48] <uli421> ...
[11:48] <uli421> bind(6, {sa_family=AF_LOCAL, sun_path="dummy/.X11-unix/X40"}, 110) = -1 ENOENT (No such file or directory)
[11:48] <uli421> ...
[11:48] <uli421> So this is a bug. Definitely
[11:50] <Ionic> no, TEMP makes sense, since TEMP and NX_TEMP are for overriding that
[11:50] <Ionic> what about TMP=dummy TMPDIR=/dummy /usr/local/nx/3.5.0/bin/nxproxy -C :40?
[11:51] <Ionic> if I run that, it correctly uses /tmp/.X11-unix
[11:51] <Ionic> bind(6, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X40"}, 110) = 0
[11:52] <Ionic> jta_1972: is TEMP defined in your environment?
[11:53] == Statler [~Georg@gwrz3.lohn24.de] has joined #x2go
[11:55] <jta_1972> Ionic: in a new bash echo $TEMP ==> /tmp/user/1003
[11:55] <Ionic> oh
[11:55] <Ionic> where is THAT coming from?!
[11:55] <Ionic> $TEMP is not a standard environment variable
[11:55] <Ionic> ($TMP and $TMPDIR are, though)
[11:55] <Ionic> oh, yes, TEMP is a standard variable, hum
[11:56] <Ionic> so it's probably set by pam_tmpdir
[11:56] <Ionic> jta_1972: okay, in that case a workaround such as export TEMP=/tmp should work

Best regards.

affects:

x2goclient (Ubuntu) → nxcomp (Ubuntu)

Revision history for this message

Mihai Moldovan (ionic) wrote on 2017-10-19:

#3

The problem lies within libxcomp3, which uses the environment variables NX_TEMP and TEMP to determine the temporary files directory (with a fallback to /tmp) and then tries to connect to $DETERMINED_TMP_DIR/.X11-unix/X$DISPLAY.

Note that TEMP has not been a typo.

Since pam_tmpdir.so sets TMP, TEMP, TMPDIR and TEMPDIR, by default nxproxy (which has its implementation in libxcomp3), will try to open /tmp/user/.../.X11-unix/X... on such systems and fail.

The easiest workaround is to remove the possibility to override the temporary directory via TEMP in libxcomp3's Loop.cpp (which we will probably also do as upstream, since the X11 UNIX socket path should not depend upon a configurable temp dir env variable - minus NX_TEMP, which can stay and is a good override value if users really need it, since it's not being set by pam_tmpdir or the like.)

Ubuntu
nxcomp package

Can't see the remote desktop

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntunxcomp package

Can't see the remote desktop

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
nxcomp package