markcmiller86
commented
2 years ago Describe the bug
I'm creating a system for launching visit sessions with the U of A super computer, and managed to get everything working with visit 3.1.4. The discussion that I had to get this far is at this link #17120.
First, WOW! 🥇 Thats really great work recalling where you started 😉
I get a couple of issues when I try to do the same thing with visit version 3.2.1.
Just wanna confirm you are trying to use a 3.2 engine (e.g. server) with a 3.2.1 client, correct? The client and server must agree in major and minor version numbers. I am pretty sure you've already guarded for that but wanted to make sure.
In some instances the program freezes after trying to connect to the remote machine before I get a chance to select data and launch my compute engine session. I can verify that the remote machine shows processes started by visit, and I see log files in the home directory, but the logs end with some indication that the connection back to the host didn't work. I usually have to end the visit program from my local machine with ctrl-c.
/groups/chrisreidy/baylyd/consults/visit_remote_support/visit3_2_1.linux-x86_64/3.2.1/linux-x86_64/bin/vcl -dir /groups/chrisreidy/baylyd/consults/visit_remote_support/visit3_2_1.linux-x86_64 -idle-timeout 480 -threads 16 -noloopback -host 10.141.250.198 -port 5602 -key 406161654b1ba84b5de4 VisIt component launcher started. ParentProcess::Connect: Called with (numRead=1, numWrite=2, argc=14, argv={/groups/chrisreidy/baylyd/consults/visit_remote_support/visit3_2_1.linux-x86_64/3.2.1/linux-x86_64/bin/vcl, -dir, /groups/chrisreidy/baylyd/consults/visit_remote_support/visit3_2_1.linux-x86_64, -idle-timeout, 480, -threads, 16, -noloopback, -host, 10.141.250.198, -port, 5602, -key, 406161654b1ba84b5de4}) ParentProcess::Connect: hostName = 10.141.250.198 ParentProcess::GetHostInfo: Calling gethostbyname("10.141.250.198") ParentProcess::Connect: port = 5602 ParentProcess::Connect: securityKey = 406161654b1ba84b5de4 ParentProcess::Connect: Creating sockets ParentProcess::Connect: Creating read sockets ParentProcess::GetClientSocketDescriptor: Set up using port 5602 ParentProcess::GetClientSocketDescriptor: Creating a socket ParentProcess::GetClientSocketDescriptor: Setting socket options ParentProcess::GetClientSocketDescriptor: Calling connect (If you see no messages after this one, VisIt was not able to connect to the client machine. Nine times out of ten, this is a firewall issue on the client machine. It could also mean that VisIt was unable to resolve the IP address for the client machine. You may need to verify the contents of /etc/hosts.) ParentProcess::GetClientSocketDescriptor: Connected socket ParentProcess::Connect: Creating write sockets ParentProcess::GetClientSocketDescriptor: Set up using port 5602 ParentProcess::GetClientSocketDescriptor: Creating a socket ParentProcess::GetClientSocketDescriptor: Setting socket options ParentProcess::GetClientSocketDescriptor: Calling connect (If you see no messages after this one, VisIt was not able to connect to the client machine. Nine times out of ten, this is a firewall issue on the client machine. It could also mean that VisIt was unable to resolve the IP address for the client machine. You may need to verify the contents of /etc/hosts.) ParentProcess::GetClientSocketDescriptor: Connected socket ParentProcess::GetClientSocketDescriptor: Set up using port 5602 ParentProcess::GetClientSocketDescriptor: Creating a socket ParentProcess::GetClientSocketDescriptor: Setting socket options ParentProcess::GetClientSocketDescriptor: Calling connect (If you see no messages after this one, VisIt was not able to connect to the client machine. Nine times out of ten, this is a firewall issue on the client machine. It could also mean that VisIt was unable to resolve the IP address for the client machine. You may need to verify the contents of /etc/hosts.) ParentProcess::GetClientSocketDescriptor: Connected socket ParentProcess::Connect: Ordering the connections. Read 0 from writeConnections[0] Read 0 from readConnections[0] Read 0 from readConnections[1] ParentProcess::Connect: Exchanging type representations. signalhandler_core: SIGSEGV!
A SEGV down in the bowels of this exchange smells like either a timing or protocol (version mismatch) issue.
The other problem that I seem to have is related to a version error. I don't fully understand how this is possible since both the client and the server versions of visit are 3.2.1.
(base) lil@vis:~/Documents/visit3_2_1.linux-x86_64/bin$ ./visit -debug 5 ./visit: 120: [[: not found System python ./frontendlauncher.py ./visit -debug 5 Running: gui3.2.1 -debug 5 ./visit: 120: [[: not found System python ./frontendlauncher.py ./visit -v 3.2 -viewer -debug 5 -geometry 744x687+550+54 -borders 26,4,4,4 -shift 0,0 -preshift 4,26 -defer -host vis -port 5600 -key 9be97f62cdab2e8f87fd Running: viewer3.2.1 -debug 5 -geometry 744x687+550+54 -borders 26,4,4,4 -shift 0,0 -preshift 4,26 -defer -host 127.0.0.1 -port 5600 ./visit: 120: [[: not found System python ./frontendlauncher.py ./visit -v 3.2 -mdserver -debug 5 -host vis -port 5601 -key 9be97f62cdab2e8f87fd Running: mdserver3.2.1 -debug 5 -host 127.0.0.1 -port 5601 Version 3.2 of VisIt does not exist.
The .visit: XXX [[: not found looks familiar. I think its a non-bashism. And, I think we've been in adjusting that code (look around line 135 in the diff) recently.
DevinBayly
Describe the bug
I'm creating a system for launching visit sessions with the University of Arizona super computer, and managed to get everything working with visit 3.1.4. The discussion that I had to get this far is at this link https://github.com/visit-dav/visit/discussions/17120.
I get a couple of issues when I try to do the same thing with visit version 3.2.1. In some instances the program freezes after trying to connect to the remote machine before I get a chance to select data and launch my compute engine session. I can verify that the remote machine shows processes started by visit, and I see log files in the home directory, but the logs end with some indication that the connection back to the host didn't work. I usually have to end the visit program from my local machine with ctrl-c.
The other problem that I seem to have is related to a version error. I don't fully understand how this is possible since both the client and the server versions of visit are 3.2.1.
This happened once with the 3.1.4 but then I started the visit client with
./visit -debug 5 -v 3.1.4instead of./visit -debug 5and then it worked.In neither of these instances did visit crash, it just either froze or presented the version error and stopped the remote connection attempt.
Desktop
I can try to provide any relevant tests and files that you need. Thanks so much!