On 02/26/17 18:08, bruce wrote: > Morn guys... > > The following works as a test ssh to fire off a remote cmd. However it > waits for the cmd to complete befor returning. I'm looking to run th > cmd as a background on the local/calling instance. Ultimaely, I'll be > testing this from py/php scripts. > > ssh -t user1(a)67.205.151.05 'cat /cloud/hash2.dat | wc -l' > > -would the following work? > > ssh -t user1(a)67.205.151.05 'cat /cloud/hash2.dat | wc -l' & It runs the (complete) local ssh cmd (including it's parameters) locally in background. If you want to run the remote cmd in background (cat /cloud/hash2.dat | wc -l) you must add the "&" before the closing "'" and not after. But this means your ssh command likely may exit before the remote cmd finishes. Is this reasonable? Kind regards Joachim Backes

Hey Jon... You are absolutely correct.. if the parent ssh terminates.. the remote process would "die".. In my use case, the remote process being fired off is actually being run under a remote "Screen" session, so it had better survive the ssh terminating!! (In testing, this has worked, so I have no reason to think the background process would be any different!

On Sun, Feb 26, 2017 at 2:17 PM, Jon LaBadie <jonfu(a)jgcomp.com&gt; wrote: > On Sun, Feb 26, 2017 at 06:40:50PM +0100, Joachim Backes wrote: >> On 02/26/17 18:08, bruce wrote: >>> Morn guys... >>> >>> The following works as a test ssh to fire off a remote cmd. However it >>> waits for the cmd to complete befor returning. I'm looking to run th >>> cmd as a background on the local/calling instance. Ultimaely, I'll be >>> testing this from py/php scripts. >>> >>> ssh -t user1(a)67.205.151.05 'cat /cloud/hash2.dat | wc -l' >>> >>> -would the following work? >>> >>> ssh -t user1(a)67.205.151.05 'cat /cloud/hash2.dat | wc -l' & >> >> It runs the (complete) local ssh cmd (including it's parameters) locally in >> background. If you want to run the remote cmd in background >> (cat /cloud/hash2.dat | wc -l) you must add the "&" before the closing "'" >> and not after. >> >> But this means your ssh command likely may exit before the remote cmd >> finishes. Is this reasonable? >> >> Kind regards >> >> Joachim Backes > > Two other considerations: > > Where is the output from the pipeline sink (wc -l in this case) > going to go? Without the ssh connection, it will go to stdout, > either closed or set to /dev/null. > > When the ssh connection terminates, I suspect its children > processes on the remote to receive the "Hang UP" (your parent > has died) signal and will likely commit suicide. > > Jon > -- > Jon H. LaBadie jonfu(a)jgcomp.com > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org

On 02/26/2017 12:34 PM, bruce wrote: > Hey Jon... > > You are absolutely correct.. if the parent ssh terminates.. the remote

Jon, we try not to top-post here. Just a nudge.

If you are using ssh to spawn a remote screen session that runs a command in the background it should work just fine, e.g.: ssh user@remote "screen command-to-run args &"

On 02/27/2017 11:35 AM, Jon LaBadie wrote: > On Mon, Feb 27, 2017 at 09:41:11AM -0800, Rick Stevens wrote: >> On 02/26/2017 12:34 PM, bruce wrote: >>> Hey Jon... >>> >>> You are absolutely correct.. if the parent ssh terminates.. the remote > ... >> >> Jon, we try not to top-post here. Just a nudge. > > I didn't Rick, you attributed the above incorrectly. > >> >> If you are using ssh to spawn a remote screen session that runs a >> command in the background it should work just fine, e.g.: >> >> ssh user@remote "screen command-to-run args &" > > I replied to the original post and the screen command was never mentioned. OOPS! My mistake. I should have poked Bruce. Sorry, Jon.

On Mon, Feb 27, 2017 at 11:44 PM, bruce <badouglas(a)gmail.com&gt; wrote: > On Mon, Feb 27, 2017 at 2:56 PM, Rick Stevens <ricks(a)alldigital.com&gt; wrote: >> On 02/27/2017 11:35 AM, Jon LaBadie wrote: >>> On Mon, Feb 27, 2017 at 09:41:11AM -0800, Rick Stevens wrote: >>>> On 02/26/2017 12:34 PM, bruce wrote: >>>>> Hey Jon... >>>>> >>>>> You are absolutely correct.. if the parent ssh terminates.. the remote >>> ... >>>> >>>> Jon, we try not to top-post here. Just a nudge. >>> >>> I didn't Rick, you attributed the above incorrectly. >>> >>>> >>>> If you are using ssh to spawn a remote screen session that runs a >>>> command in the background it should work just fine, e.g.: >>>> >>>> ssh user@remote "screen command-to-run args &" >>> >>> I replied to the original post and the screen command was never mentioned. >> >> OOPS! My mistake. I should have poked Bruce. Sorry, Jon. > > hey... no poking in here!!! > More clarification.... The following works... ssh -t crawl_user(a)1.2.3.4 cp /foot/start.php /ctmp/. Howvever, i've been putzing with a way to have the local ssh run in the background, with no success... ssh -t crawl_user(a)1.2.3.4 "cp /foot/start.php /ctmp/. " & Seems to place the ssh in the background (ps -aux) shows it running, but it never dies.. I've tried different approaches > \dev\null & etc.. with little luck... Here's why Im looking to do this: My use case/test has a bunch of digital ocean droplets, and the process has a number of things that ned to be done to each droplet on initialization (I know, whynot create a base instance with what's needed, and clone that one!) So the current process does a simple loop through the init process, doing the remote/ssh into the target instances... This process works, but is time consuming. So I've wondered how one could run a local ssh in the background, which would/should allow the process to run faster... loop (ssh user@ip1 remote_process_1) & so the entire local ssh process runs as a background (ssh user@ip1 remote_process_2) & so the entire local ssh process runs as a background (ssh user@ip1 remote_process_3) & so the entire local ssh process runs as a background