xpra icon
Bug tracker and wiki

Opened 2 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#2932 closed defect (fixed)

skipping system Xorg

Reported by: Jens H. Goebbert Owned by: Jens H. Goebbert
Priority: minor Milestone: 4.1
Component: html5 Version: 4.0.x
Keywords: Xorg Cc:

Description

Hello Antoine,

thank you for this great tool!
I love it and integrated it into our JupyterLab? service lately at our supercomputing centre:
https://github.com/FZJ-JSC/jupyter-xprahtml5-proxy

On some nodes here Xorg is installed already, but I cannot use the system one. Good that Xpra can use Xdummy here - but I had to add a patch to avoid that Xpra takes the wrong Xorg.

I wonder why you want to choose Xorg from a special location over the one found in PATH. I am not sure if this is a bug or a feature. Anyway, I need the following patch to use Xpra here:

diff -Naur xpra-4.0.4.orig/xpra/scripts/config.py xpra-4.0.4/xpra/scripts/config.py
--- xpra-4.0.4.orig/xpra/scripts/config.py      2020-09-27 20:11:39.000000000 +0200
+++ xpra-4.0.4/xpra/scripts/config.py   2020-11-11 19:18:28.619408000 +0100
@@ -60,6 +60,13 @@

 def get_xorg_bin():
     # Detect Xorg Binary
+
+    #look for it in $PATH:
+    for x in os.environ.get("PATH").split(os.pathsep): # pragma: no cover
+        xorg = os.path.join(x, "Xorg")
+        if os.path.isfile(xorg):
+            return xorg
+
     if is_arm() and is_Debian() and os.path.exists("/usr/bin/Xorg"):
         #Raspbian breaks if we use a different binary..
         return "/usr/bin/Xorg"
@@ -72,11 +79,6 @@
               ):
         if os.path.exists(p):
             return p
-    #look for it in $PATH:
-    for x in os.environ.get("PATH").split(os.pathsep): # pragma: no cover
-        xorg = os.path.join(x, "Xorg")
-        if os.path.isfile(xorg):
-            return xorg
     return None

Best regards,
Jens Henrik

Change History (6)

comment:1 Changed 2 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to Jens H. Goebbert

I had to add a patch to avoid that Xpra takes the wrong Xorg.

What distribution is this?
Which one is the correct one? And which one is the wrong one?

comment:2 Changed 2 weeks ago by Jens H. Goebbert

Hello Antoine,

we are running CentOS7/8 on all our clusters, but I think it is more the multiuser setup and the side-wide software installation, which results in some specialities:

1) we use to manage our software through EasyBuild? for all nodes in a similar manner -> so I create a central installation and configuration script for Xpra
2) our nodes partly have GPUs and partly have no GPUs
3) some GPU nodes (mostly login nodes) run an Xserver but some do not (used purely for computation)

Best regards,
Jens Henrik
4) if a system-Xserver is running on a GPU node its purpose is to enable the use of VirtualGL
5) the os-image must be small, as it is pushed to the thousands of diskless nodes at startup and takes part of the main memory. So any extra software is included by mounting certain directories afterwards. Hence the path to X can differ.

So the bottom line is: I cannot use/trust the systems Xserver, even if it is installed.

Hence, I added a side-wide installation of an Xserver through our software management framework EasyBuild?. This Xserver can be loaded mit "lmod" by any user on any node and fits exactly and garanteed the needs of Xpra (Loading here means just adding some paths to $PATH and $LD_LIBRARY_PATH).

This works fine as long as software, which looks for Xorg like Xpra, does not search for binarys at special hardcoded paths but stick to the search pattern of $PATH

This might be a quite special setup and therefor cannot be considered by Xpra.
Anyway, why do you want to make Xpra first check these special hardcoded paths and _afterwards_ $PATH. Shouldn´t it be the other way round.
(that would makes it possible to users to skip the systems Xorg to use their own installation of a Xserver in $HOME for example)

comment:3 Changed 2 weeks ago by Antoine Martin

Anyway, why do you want to make Xpra first check these special hardcoded paths and _afterwards_ $PATH. Shouldn´t it be the other way round.

No. We want the real Xorg and not one of the wrapper scripts often found in $PATH.

As per comment:1, please give an example of "good" Xorg path you want to use ahead of the system one.

I think that the easiest solution is to add an optional environment variable to override the Xorg path detection: does r27919 work for you?

XPRA_XORG_PATH=/wherever/lives/your/Xorg python ./setup.py install ...

comment:4 Changed 2 weeks ago by Jens H. Goebbert

Yes, the optional environment variable XPRA_XORG_PATH would be perfect.
Thanks!

comment:5 Changed 2 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

Backport to older branches: r27920.

As per comment:1, can you tell us what this path looks like?

comment:6 Changed 2 weeks ago by Jens H. Goebbert

This is for example the path to Xorg installed for the cluster "juwels" in the software stage "2020" with compiler "gcc/9.3.0":
/p/software/juwels/stages/2020/software/XServer/1.20.9-GCCcore-9.3.0/bin/Xorg

Note: See TracTickets for help on using tickets.