Cannot connect to Catalyst on Mac OS at v5.8.1
I was able to reproduce and root cause #17752 (closed), opening a new issue (as I can't reopen it), even though it's old.
Tldr; If you hit this behavior, make sure your hostname
is in /etc/hosts
or otherwise resolvable.
Note this discussion continued: https://discourse.paraview.org/t/cannot-connect-to-catalyst-live-visualization-on-mac-os-x/301/2
It replicates with v5.8.1, using this example: https://gitlab.kitware.com/paraview/paraview/-/tree/master/Examples/Catalyst/CxxFullExample . It does not replicate with master (see below).
( 13.455s) [pvbatch ] vtkSocket.cxx:464 ERR| vtkClientSocket (0x7fd858dcb730): Socket error in call to connect. Permission denied.
( 13.455s) [pvbatch ] vtkClientSocket.cxx:51 ERR| vtkClientSocket (0x7fd858dcb730): Failed to connect to server Patricks-MacBook-Pro.local:22223
( 13.455s) [pvbatch ]vtkSocketCommunicator.c:692 ERR| vtkSocketCommunicator (0x7fd85a11f430): Can not connect to Patricks-MacBook-Pro.local on port 22223
Immediately after connecting to the UI, the UI sends back to the catalyst (in-situ) program the hostname so it can open auxiliary connections. The connection to port 22223 is normal and necessary, apparently. See:
- Sending the hostname: https://gitlab.kitware.com/paraview/paraview/-/blob/master/Remoting/Live/vtkLiveInsituLink.cxx#L659
- Receive and connect to it: https://gitlab.kitware.com/paraview/paraview/-/blob/master/Remoting/Live/vtkLiveInsituLink.cxx#L764
The catalyst app then tries to look up the hostname. This is usually results in the localhost address, via a /etc/hosts
file. However, OS X doesn't appear to populate the hostname by default, which ubuntu does. This is easy to check with getent hosts `hostname`
, which will normally work on Ubuntu, and does not on OS X (on Catalina, anyway).
Due to a bug in the VTK socket function (which I opened: vtk/vtk#17978), it incorrectly tries to connect to a return value -1
, which it interprets as 255.255.255.255
, which accidentally trips the "permissions" error seen above.
If that bug is fixed, then this would fail as unable to look up the hostname.
On master it looks like the socket connection to the hostname doesn’t actually happen, only to localhost
, at least out of the box. However, per above, some of the related code (that grabs the hostname
) still seems to be present, so I’m not sure what changed.
The remaining question here is a) whether master still can/will send data to hostname
on master, and whether it’s worth doing anything to improve the experience on the latest release.
How does this work if the UI is on a remote machine whose hostname is not resolvable? This seems common for user desktops.