Ubuntu 26.04 ParaView compile and run issues

ParaView Support
1

Dear ParaView support

I have moved to an Ubuntu 26.04 laptop with an NVIDIA GPU, and attempting to compile ParaView v6.1. As a reference, I have also downloaded the pre-compiled binary (ParaView-6.1.0-MPI-Linux-Python3.12-x86_64) which I am able to run, in parallel with

./bin/mpiexec -n 2 ./bin/pvserver

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia ./bin/paraview --server=localhost

My own compilation works fine without MPI, but if setting PARAVIEW_USE_MPI=ON, I cannot run anything (paraview standalone, or a combination of pvserver+paraview) because I get stuck opening sockets. Here is a partial output of strace (the first part is successfull), followed by the blocking part

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 25
connect(25, {sa_family=AF_UNIX, sun_path=@“/tmp/.X11-unix/X0”}, 20) = 0
getpeername(25, {sa_family=AF_UNIX, sun_path=@“/tmp/.X11-unix/X0”}, [124 => 20]) = 0
uname({sysname=“Linux”, nodename=“paradiso”, …}) = 0
access(“/run/user/1001/.mutter-Xwaylandauth.ASGBP3”, R_OK) = 0
openat(AT_FDCWD, “/run/user/1001/.mutter-Xwaylandauth.ASGBP3”, O_RDONLY) = 26

the blocking part here:
close(25) = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 25
connect(25, {sa_family=AF_UNIX, sun_path=@“/tmp/.X11-unix/X1”}, 20

on this second call to connect, execution gets stuck. My colleagues, more knowledgeable than me about sockets and ssh issues tell me that this is caused by Xwayland issues with opening/listening with multiple processes. Frankly, this is beyond my zone of comfort.

Question to the ParaView developers. Which options would you suggest (for the MPI part, and the rendering part) to get past these issues? Are the compile commands available to see how
ParaView Build ID: superbuild af9bb3207d40b64f97c64a9c319d483ff3b17d03 (!1332)
was built?I am using mpich v4.3.2

TIA

2

I had the same issue on my ubuntu 26.04 laptop. With USE_MPI=ON, paraview GUI was not starting up. So I switched to USE_MPI=OFF and everything works normally. Sorry, I haven’t done any debugging yet, so I don’t have any logs to share at the moment, but it looks like I saw the same issue. I am commenting here just to follow the thread if someone finds or shares a solution.
I am using an Open MPI v5.0.10

3

I observed that the ParaView GUI does not start for exactly the same reason I noted above. It gets stuck opening the socket I listed => connect(…@”/tmp/.X11-unix/X1”)

4

Do you have Xwayland installed ? You mention it may be related but you never mentionned installing it.

5

Yes, Wayland is not just installed, it is the sole default display server for Ubuntu 26.04 LTS. Starting with release 25.10 the “Ubuntu” session in GDM runs exclusively on Wayland.

6

I’m talking about Xwayland, the Xorg compability layer on top of Wayland.

7

dpkg -l | grep xwayland

ii xwayland 2:24.1.10-1 amd64 X server for running X clients under Wayland

8

I have found the solution in the HWLOC documentation. Portable Hardware Locality (hwloc) Documentation: v2.3.0

the key is to blacklist the gl component, responsible to probe the NV-CONTROL X extension (NVCtrl library) which creates OS device objects such as :0.0 corresponding to NVIDIA displays.

Thus, I run export HWLOC_COMPONENTS=-gl and ParaView is happy.

9

Great solution @jfavre !

@sherin.sugathan could you check on your side ? Then I would move this into our FAQ.

10

Thank you @jfavre and @mwestphal !
Just wanted to send a quick reply. Unfortunately, the solution is not working for me. Please hold putting to FAQ. I will send some more information shortly.

11

What worked for me was:
export HWLOC_COMPONENTS=-gl,-opencl
,which means I had to blacklist multiple stuff.
From my logs (attached) pvgdb.txt (21.2 KB), my understanding is that hwloc tries to query OpenCL too. When I set up my laptop, I also installed CUDA, so I guess some OpenCLrelated components came along. Because of that, OpenCL probably became another component I had to blacklist.

This also made me check the hwloc documentation:

There I see: “Additionally hwloc can detect the locality PCI devices as well as software devices to manipulate accelerators (OpenCL, NVIDIA CUDA, AMD ROCm, Intel LevelZero, NEC Vector Engine, etc.), network and InfiniBand interfaces, etc. ”

So maybe the exact workaround depends on which accelerator stack is present on the system? I dont knwo.

One thing I am still wondering about is whether starting paraview/pvserver this way could cause any side effects.. I found a “maybe” related issue at: https://github.com/open-mpi/ompi/issues/13838. In that discussion, the last comment says: “Unless you really care about GL device locality, you likely want to set HWLOC_COMPONENTS=-gl in your environment.” That raised a few more questions for me: does this workaround have any side effects for ParaView when using MPI in multi-GPU setups? Does ParaView actually need to cehck locality for MPI or distributed rendering stuff? I dont know.

For now, the solution workaround is working for me, but I am not a fan of workarounds. :smiley: So it would be nice to know whether this workaround is considered safe for normal ParaView MPI usage.