Hey Burlen, on the bug report page for 10283, I think you need to fix the command line you are testing with :
$ ssh remote cmd1 && cm2 will execute cmd1 on remote and cmd2 locally. It should be: $ ssh remote "cmd1 && cmd2" Pat On Fri, Apr 30, 2010 at 9:12 AM, pat marion <pat.mar...@kitware.com> wrote: > I have applied your patch. I agree that paraview should explicity close > the child process. But... what I am pointing out is that calling > QProcess::close() does not help in this situation. What I am saying is > that, even when paraview does kill the process, any commands run by ssh on > the other side of the netpipe will be orphaned by sshd. Are you sure you > can't reproduce it? > > > $ ssh localhost sleep 1d > $ < press control-c > > $ pidof sleep > $ # sleep is still running > > Pat > > > On Fri, Apr 30, 2010 at 2:08 AM, burlen <burlen.lor...@gmail.com> wrote: > >> Hi Pat, >> >> From my point of view the issue is philosophical, because practically >> speaking I couldn't reproduce the orphans with out doing something a little >> odd namely, ssh ... && sleep 1d. Although the fact that a user reported >> suggests that it may occur in the real world as well. The question is this: >> should an application explicitly clean up resources it allocates? or should >> an application rely on the user not only knowing that there is the potential >> for a resource leak but also knowing enough to do the right thing to avoid >> it (eg ssh -tt ...)? In my opinion, as a matter of principle, if PV spawns a >> process it should explicitly clean it up and there should be no way it can >> become an orphan. In this case the fact that the orphan can hold ports open >> is particularly insidious, because further connection attempt on that port >> fails with no helpful error information. Also it is not very difficult to >> clean up a spawned process. What it comes down to is a little book keeping >> to hang on to the qprocess handle and a few lines of code called from >> pqCommandServerStartup destructor to make certain it's cleaned up. This is >> from the patch I submitted when I filed the bug report. >> >> + // close running process >> + if (this->Process->state()==QProcess::Running) >> + { >> + this->Process->close(); >> + } >> + // free the object >> + delete this->Process; >> + this->Process=NULL; >> >> I think if the cluster admins out there new which ssh options >> (GatewayPorts etc) are important for ParView to work seamlessly, then they >> might be willing to open them up. It's my impression that the folks that >> build clusters want tools like PV to be easy to use, but they don't >> necessarily know all the in's and out's of confinguring and running PV. >> >> Thanks for looking at this again! The -tt option to ssh is indeed a good >> find. >> >> Burlen >> >> pat marion wrote: >> >>> Hi all! >>> >>> I'm bringing this thread back- I have learned a couple new things... >>> >>> ----------------------- >>> No more orphans: >>> >>> Here is an easy way to create an orphan: >>> >>> $ ssh localhost sleep 1d >>> $ <press control c> >>> >>> The ssh process is cleaned up, but sshd orphans the sleep process. You >>> can avoid this by adding '-t' to ssh: >>> >>> $ ssh -t localhost sleep 1d >>> >>> Works like a charm! But then there is another problem... try this >>> command from paraview (using QProcess) and it still leaves an orphan, doh! >>> Go back and re-read ssh's man page and you have the solution, use '-t' >>> twice: ssh -tt >>> >>> ------------------------- >>> GatewayPorts and portfwd workaround: >>> >>> In this scenario we have 3 machines: workstation, service-node, and >>> compute-node. I want to ssh from workstation to service-node and submit a >>> job that will run pvserver on compute-node. When pvserver starts on >>> compute-node I want it to reverse connect to service-node and I want >>> service-node to forward the connection to workstation. So here I go: >>> >>> $ ssh -R11111:localhost:11111 service-node qsub start_pvserver.sh >>> >>> Oops, the qsub command returns immediately and closes my ssh tunnel. >>> Let's pretend that the scheduler doesn't provide an easy way to keep the >>> command alive, so I have resorted to using 'sleep 1d'. So here I go, using >>> -tt to prevent orphans: >>> >>> $ ssh -tt -R11111:localhost:11111 service-node "qsub start_pvserver.sh >>> && sleep 1d" >>> >>> Well, this will only work if GatewayPorts is enabled in sshd_config on >>> service-node. If GatewayPorts is not enabled, the ssh tunnel will only >>> accept connections from localhost, it will not accept a connection from >>> compute-node. We can ask the sysadmin to enable GatewayPorts, or we could >>> use portfwd. You can run portfwd on service-node to forward port 22222 to >>> port 11111, then have compute-node connect to service-node:22222. So your >>> job script would launch pvserver like this: >>> >>> pvserver -rc -ch=service-node -sp=22222 >>> >>> Problem solved! Also convenient, we can use portfwd to replace 'sleep >>> 1d'. So the final command, executed by paraview client: >>> >>> ssh -tt -R 11111:localhost:11111 service-node "qsub start_pvserver.sh && >>> portfwd -g -c fwd.cfg" >>> >>> Where fwd.cfg contains: >>> >>> tcp { 22222 { => localhost:11111 } } >>> >>> >>> Hope this helps! >>> >>> Pat >>> >>> On Fri, Feb 12, 2010 at 7:06 PM, burlen <burlen.lor...@gmail.com<mailto: >>> burlen.lor...@gmail.com>> wrote: >>> >>> >>> Incidentally, this brings up an interesting point about >>> ParaView with client/server. It doesn't try to clean up it's >>> child processes, AFAIK. For example, if you set up this ssh >>> tunnel inside the ParaView GUI (e.g., using a command instead >>> of a manual connection), and you cancel the connection, it >>> will leave the ssh running. You have to track down the ssh >>> process and kill it yourself. It's minor thing, but it can >>> also prevent future connections if you don't realize there's a >>> zombie ssh that kept your ports open. >>> >>> I attempted to reproduce on my kubuntu 9.10, qt 4.5.2 system, with >>> slightly different results, which may be qt/distro/os specific. >>> >>> On my system as long as the process ParaView spawns finishes on >>> its own there is no problem. That's usually how one would expect >>> things to work out since when the client disconnects the server >>> closes followed by ssh. But, you are right that PV never >>> explicitly kills or otherwise cleans up after the process it >>> starts. So if the spawned process for some reason doesn't finish >>> orphan processes are introduced. >>> >>> I was able to produce orphan ssh processes, giving the PV client a >>> server start up command that doesn't finish. eg >>> >>> ssh ... pvserver ... && sleep 100d >>> >>> I get the situation you described which prevents further >>> connection on the same ports. Once PV tries and fails to connect >>> on th eopen ports, there is crash soon after. >>> >>> I filed a bug report with a patch: >>> http://www.paraview.org/Bug/view.php?id=10283 >>> >>> >>> >>> Sean Ziegeler wrote: >>> >>> Most batch systems have an option to wait until the job is >>> finished before the submit command returns. I know PBS uses >>> "-W block=true" and that SGE and LSF have similar options (but >>> I don't recall the precise flags). >>> >>> If your batch system doesn't provide that, I'd recommend >>> adding some shell scripting to loop through checking the queue >>> for job completion and not return until it's done. The sleep >>> thing would work, but wouldn't exit when the server finishes, >>> leaving the ssh tunnels (and other things like portfwd if you >>> put them in your scripts) lying around. >>> >>> Incidentally, this brings up an interesting point about >>> ParaView with client/server. It doesn't try to clean up it's >>> child processes, AFAIK. For example, if you set up this ssh >>> tunnel inside the ParaView GUI (e.g., using a command instead >>> of a manual connection), and you cancel the connection, it >>> will leave the ssh running. You have to track down the ssh >>> process and kill it yourself. It's minor thing, but it can >>> also prevent future connections if you don't realize there's a >>> zombie ssh that kept your ports open. >>> >>> >>> On 02/08/10 21:03, burlen wrote: >>> >>> I am curious to hear what Sean has to say. >>> >>> But, say the batch system returns right away after the job >>> is submitted, >>> I think we can doctor the command so that it will live for >>> a while >>> longer, what about something like this: >>> >>> ssh -R XXXX:localhost:YYYY remote_machine >>> "submit_my_job.sh && sleep >>> 100d" >>> >>> >>> pat marion wrote: >>> >>> Hey just checked out the wiki page, nice! One >>> question, wouldn't this >>> command hang up and close the tunnel after submitting >>> the job? >>> ssh -R XXXX:localhost:YYYY remote_machine submit_my_job.sh >>> Pat >>> >>> On Mon, Feb 8, 2010 at 8:12 PM, pat marion >>> <pat.mar...@kitware.com <mailto:pat.mar...@kitware.com> >>> <mailto:pat.mar...@kitware.com >>> >>> <mailto:pat.mar...@kitware.com>>> wrote: >>> >>> Actually I didn't write the notes at the hpc.mil >>> <http://hpc.mil> <http://hpc.mil> >>> >>> link. >>> >>> Here is something- and maybe this is the problem that >>> Sean refers >>> to- in some cases, when I have set up a reverse ssh >>> tunnel from >>> login node to workstation (command executed from >>> workstation) then >>> the forward does not work when the compute node >>> connects to the >>> login node. However, if I have the compute node >>> connect to the >>> login node on port 33333, then use portfwd to forward >>> that to >>> localhost:11111, where the ssh tunnel is listening on >>> port 11111, >>> it works like a charm. The portfwd tricks it into >>> thinking the >>> connection is coming from localhost and allow the ssh >>> tunnel to >>> work. Hope that made a little sense... >>> >>> Pat >>> >>> >>> On Mon, Feb 8, 2010 at 6:29 PM, burlen >>> <burlen.lor...@gmail.com <mailto:burlen.lor...@gmail.com> >>> <mailto:burlen.lor...@gmail.com >>> <mailto:burlen.lor...@gmail.com>>> wrote: >>> >>> Nice, thanks for the clarification. I am guessing that >>> your >>> example should probably be the recommended approach rather >>> than the portfwd method suggested on the PV wiki. :) I >>> took >>> the initiative to add it to the Wiki. KW let me know >>> if this >>> is not the case! >>> >>> >>> http://paraview.org/Wiki/Reverse_connection_and_port_forwarding#Reverse_connection_over_an_ssh_tunnel >>> >>> >>> >>> Would you mind taking a look to be sure I didn't miss >>> anything >>> or bollix it up? >>> >>> The sshd config options you mentioned may be why your >>> method >>> doesn't work on the Pleiades system, either that or >>> there is a >>> firewall between the front ends and compute nodes. In >>> either >>> case I doubt the NAS sys admins are going to >>> reconfigure for >>> me :) So at least for now I'm stuck with the two hop ssh >>> tunnels and interactive batch jobs. if there were >>> someway to >>> script the ssh tunnel in my batch script I would be >>> golden... >>> >>> By the way I put the details of the two hop ssh tunnel >>> on the >>> wiki as well, and a link to Pat's hpc.mil >>> <http://hpc.mil> <http://hpc.mil> >>> >>> notes. I don't dare try to summarize them since I've never >>> used portfwd and it refuses to compile both on my >>> workstation >>> and the cluster. >>> >>> Hopefully putting these notes on the Wiki will save future >>> ParaView users some time and headaches. >>> >>> >>> Sean Ziegeler wrote: >>> >>> Not quite- the pvsc calls ssh with both the tunnel options >>> and the commands to submit the batch job. You don't even >>> need a pvsc; it just makes the interface fancier. As long >>> as you or PV executes something like this from your >>> machine: >>> ssh -R XXXX:localhost:YYYY remote_machine submit_my_job.sh >>> >>> This means that port XXXX on remote_machine will be the >>> port to which the server must connect. Port YYYY (e.g., >>> 11111) on your client machine is the one on which PV >>> listens. You'd have to tell the server (in the batch >>> submission script, for example) the name of the node and >>> port XXXX to which to connect. >>> >>> One caveat that might be causing you problems, port >>> forwarding (and "gateway ports" if the server is running >>> on a different node than the login node) must be enabled >>> in the remote_machine's sshd_config. If not, no ssh >>> tunnels will work at all (see: man ssh and man >>> sshd_config). That's something that an administrator >>> would need to set up for you. >>> >>> On 02/08/10 12:26, burlen wrote: >>> >>> So to be sure about what you're saying: Your .pvsc >>> script ssh's to the >>> front end and submits a batch job which when it's >>> scheduled , your batch >>> script creates a -R style tunnel and starts pvserver >>> using PV reverse >>> connection. ? or are you using portfwd or a second ssh >>> session to >>> establish the tunnel ? >>> >>> If you're doing this all from your .pvsc script >>> without a second ssh >>> session and/or portfwd that's awesome! I haven't been >>> able to script >>> this, something about the batch system prevents the >>> tunnel created >>> within the batch job's ssh session from working. I >>> don't know if that's >>> particular to this system or a general fact of life >>> about batch systems. >>> >>> Question: How are you creating the tunnel in your >>> batch script? >>> >>> Sean Ziegeler wrote: >>> >>> Both ways will work for me in most cases, i.e. a >>> "forward" connection >>> with ssh -L or a reverse connection with ssh -R. >>> >>> However, I find that the reverse method is more >>> scriptable. You can >>> set up a .pvsc file that the client can load and >>> will call ssh with >>> the appropriate options and commands for the >>> remote host, all from the >>> GUI. The client will simply wait for the reverse >>> connection from the >>> server, whether it takes 5 seconds or 5 hours for >>> the server to get >>> through the batch queue. >>> >>> Using the forward connection method, if the server >>> isn't started soon >>> enough, the client will attempt to connect and >>> then fail. I've always >>> had to log in separately, wait for the server to >>> start running, then >>> tell my client to connect. >>> >>> -Sean >>> >>> On 02/06/10 12:58, burlen wrote: >>> >>> Hi Pat, >>> >>> My bad. I was looking at the PV wiki, and >>> thought you were talking about >>> doing this without an ssh tunnel and using >>> only port forward and >>> paraview's --reverse-connection option . Now >>> that I am reading your >>> hpc.mil <http://hpc.mil> <http://hpc.mil> post I see >>> >>> what you >>> mean :) >>> >>> Burlen >>> >>> >>> pat marion wrote: >>> >>> Maybe I'm misunderstanding what you mean >>> by local firewall, but >>> usually as long as you can ssh from your >>> workstation to the login node >>> you can use a reverse ssh tunnel. >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com <http://www.kitware.com> >>> <http://www.kitware.com> >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Please keep messages on-topic and check the >>> ParaView Wiki at: >>> http://paraview.org/Wiki/ParaView >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.paraview.org/mailman/listinfo/paraview >>> >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview