[Saga-devel] saga SVN commit 3251: /trunk/adaptors/ssh/ssh_job/

amerzky at cct.lsu.edu amerzky at cct.lsu.edu
Fri Jan 9 06:09:23 CST 2009


User: amerzky
Date: 2009/01/09 06:09 AM

Added:
 /trunk/adaptors/ssh/ssh_job/
  README

Log:
 README

File Changes:

Directory: /trunk/adaptors/ssh/ssh_job/
=======================================

File [added]: README
Delta lines: +29 -0
===================================================================
--- trunk/adaptors/ssh/ssh_job/README	2009-01-09 12:01:58 UTC (rev 3250)
+++ trunk/adaptors/ssh/ssh_job/README	2009-01-09 12:09:14 UTC (rev 3251)
@@ -0,0 +1,29 @@
+
+The ssh job adaptor creates a local job service instance, and
+submits remote job requests to that instance, as ssh jobs.
+
+Thus, 
+
+  saga::job::service js ("ssh://remote.host.net");
+  saga::job::job j = js.run_job ("/bin/touch /tmp/test");
+
+gets effectively translated into
+
+  saga::job::service js ("fork://localhost");
+  saga::job::job j = js.run_job ("/bin/ssh -i <key> <user>@remote.host.net /bin/touch /tmp/test");
+
+<key> and <user> come from the used ssh context in the current
+session (the js c'tor is trying to find a valid context for the
+given host, and will fail if non is available).
+
+main limitation of the current approach: signals are sent to the
+local ssh process, _not_ to the remotely started process.  That
+is probably not what the user wants.  That also holds for
+suspend/resume, which act on the local ssh process.
+
+reason: I simply do not know how to find the PID of the remote
+job - ssh does not report it.  BTW: using libssh would not solve
+that problem.  At the moment, I can't think of a clean solution.
+
+feedback: Andre Merzky <andre at merzky.net>
+



More information about the saga-devel mailing list