I’m having the same issue with 5.11.2. Server log reports “client connected” but client is frozen with “waiting for connection to server”. Can’t use the “cancel” button either. The process has to be killed.
Same with Paraview 5.12.0. Client running on Windows 11 and Server on Ubuntu 20.04. Exact same version on both. Did anyone find a workround?
@fpradelli94 I didn’t find a robust solution to this, but I did find the issue to be temperamental. Sometimes it worked and sometimes it didn’t.
A few steps I tried that can sometimes help are: delete known_hosts file in .ssh folder; run paraview as admin; install paraview as opposed to using portable version; reinstalling paraview; restarting client; or trying some combination of these.
I am not clear which, if any of these steps actually helped, but they seemed to fix the problem temporarily sometimes. Other times, these steps didn’t seem to help at all.
Sorry that that isn’t very helpful.
@fpradelli94 – I’ve found that if you use the regular (not headless) ParaView’s pvserver on the Linux server that it seems to work more robustly / connects quicker. For example:
@NotDrJeff : Are you using a special SSH setup ?
@fpradelli94 : just tested here, it works fine
@GregVernon : just tested here, it works fine
@mwestphal I’m not an expert on ssh, so I can’t say if it’s a “special” set up. I am in a university using an HPC that is on the same WAN. It could be a firewall or hostkey issue, but I really don’t know. I have encountered the same problem conneting from inside and outside our network. Ialso know I have issues with “domain name spoofing” warnings a lot, and I usually have to delete my known_hosts file to get access to my HPC.
As mentioned, this is an intermittant issue for me. Very frustrating when it happens, but it doesn’t always happen, and usually trying some of the steps above will fix it, at least temporarily.
Unless you are configuring ParaView to use SSH explicitely, ParaView client server mechanism does not rely on SSH at all.
@mwestphal sorry, I should have mentioned that I use an ssh tunnel to connect a localhost port to a port on the HPC.
Then your solution is probably specific to your setup. Here is how I debug SSH tunelling in general:
(this is about reverse tunelling but the usage of python server is a perfectly valid way to check the tunnelling is working)
@mwestphal Thanks Mathieu. I’ll have a look at that when I get a chance.
All the best.
Thank you guys for your kind support.
@NotDrJeff I am testing your recommendation. So far it didn’t work yet.
@GregVernon I am using the regular Paraview indeed.
@mwestphal I don’t know what’s happeining then. Might it be a problem related to my VPN? I am using a VPN to connect with the office network. In the office used to work fine.
Are you able to ping through the VPN ? To connect using ssh ?
@mwestphal Yep, I actually run pvserver using ssh so the server is reachable.
I even get “client connected” when I start the connection and the RAM of the server is visible on the GUI (the bar in the lower-right), so it looks like something is working.
Still, it sticks to “Waiting for connection to sever”.
I’m afraid I’m unable to reproduce your issue, you will need to identify the cause of the issue which must be network related somehow.
I’ve also experienced some inconsistent behavior with 5.12.0 when trying to connect (Windows 11 client and EL7 Linux server). For me, on the client side the pipeline “builtin:” icon changes to indicate a connection but the connection dialog doesn’t disappear. On the server side I get the “client connected” message but then it says “connection refused” after.
Usually just killing the processes and trying again has worked fine.
It’s been so inconsistent that I had chalked it up to some kind of “me issue”, but figured I would share since I saw this post.
Hi @mwestphal
According to @fpradelli94, the connection is established and the RAM status is also showing.
The user is not able to use paraview because the dialog is not closing. Note that the dialog is actually not waiting for the connection to establish. Since he is using an HPC, there is a chance that he gets a message that says “Display is not accessible on the server side. Remote rendering will be disabled.”. The message is a warning box according to the paraview source.
A problem arises to the user because warning box will appear behind the modal connection dialog window. The situation is that the dialog window is not frozen but just waiting for the user to acknowledge the hidden warning message box. The solution is to make those warning messages appear on top of the modal connection dialog window in ubuntu based distributions.
Interesting, If I understand well the user can just click on the dialog and then click ok to “fix” the issue, is that correct ?
Yes, that is correct but doing so is tricky and most users will not see that there is background message… I did some more testing. When this issue happens, one has to resize the connection dialog box to minimum and then you will see 5% of the background message window. I had to try several clicks on the corner of the window to close the background. After closing the background message, then I am able to interact and close the connection message dialog.
Sometimes, you don’t get this issue, because in my observation, the connection message closes before the warning message dialog appears.
I finally understand the problem now. Yes. this is an issue and it should be fixed.
Please open an issue on https://gitlab.kitware.com/paraview/paraview/-/issues
1 Like
I have raised an issue. Thank you for making things better! ParaView is a great tool because of people like you!