[ET Trac] [Einstein Toolkit] #769: Execute remote commands in the background

Einstein Toolkit trac-noreply at einsteintoolkit.org
Mon Mar 12 11:31:45 CDT 2012


#769: Execute remote commands in the background
-------------------------+--------------------------------------------------
 Reporter:  eschnett     |       Owner:  eschnett
     Type:  enhancement  |      Status:  new     
 Priority:  minor        |   Milestone:          
Component:  SimFactory   |     Version:          
 Keywords:               |  
-------------------------+--------------------------------------------------
 In response to a discussion on the mailing list, I replied:

 What we need here is an unsafe delayed-execution mechanism. So far,
 Simfactory provides the safe version of these mechanisms -- it is safe
 because all files are copied into the simulation directory, so that
 the resulting simulation is self-contained. Since this takes time, we
 are now looking for an unsafe mechanism that works much faster, but
 could fail. (For example, if one modified the source tree while
 Simfactory is still copying test results, the resulting simulation may
 be inconsistent.)

 I believe the standard Unix mechanism is "nohup". For example, after
 logging in, you would say "nohup sim create-submit mytests --testsuite
 --procs 2 &" (note the ampersand to make it run in the background).
 What we now want is the same thing, except without logging in
 manually.

 A current work-around may be something like:

 ./bin/sim --remote ranger execute 'nohup sleep 100 </dev/null
 >/dev/null 2>&1 & :'

 This executes a certain command on Ranger without waiting for the
 result. It is necessary to redirect I/O so that ssh finishes. The
 final ":" is a null command to obtain a legal shell syntax --
 Simfactory expects the command to end without a terminator (such as
 "&" or ";").

 If you replace the "sleep 100" with any other command (e.g. "sim
 submit"), things may work.

 In the long term, this should become an option to "--remote", e.g.
 "--remote-background". There should then also be a way to retrieve the
 output generated by this command (which necessarily remains on the
 remote system).

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/769>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list