ssh/screen question - thread

[bruce]

Hey Ladies/Gents.

This follows the other thread i posted over the last few weeks on
devOPS stuff for managing groups of remote droplets/vms.

My approach for now to implement clusterSSH as well as screen to be
able to auto gen the remote droplets, and to be able to ssh into them
to view status, as well as to track progress, and run remote processes
with the screen env.

I'm currently testing the screen function to get more familiar with
it, and running into an issue.

I generate a basic test screen session, with a name. This session is there.
  screen -ls
shows the session and i can pop another term, and ssh into the box,,
and attach to the screen session
  screen -r 'testname' gets into the session.

However, when I attempt to do a simple test, to run a remote cmd
within the remote ssh/screen env, I run into issues. I get an error in
that the ssh/screen/cmd needs a terminal

-----Must be connected to a terminal.

Ive tested/tried a few different iterations of the ssh/screen/ls to
try to get this to work.

//--this actually generates the screen sesstion on the remote box, no issues
ssh crawl_user@192.81.214.49 "screen -d -m -S 'testname' "

//--which of these (or something else) to remotely run ls in the
ssh/screen session??
--which of these??
ssh crawl_user@192.81.214.49 'screen -m -d -r "testname" "ls" '
ssh crawl_user@192.81.214.49 'screen  -r "testname" "ls" '

ssh -t crawl_user@192.81.214.49 'screen  -r "testname" "nhup ls &" '
  --- this almost seems to work, but the process hangs, leaving the
user in the remote term, in other words, it doesn't run, and return to
the calling term

I've been looking at the net/goog/SO/etc.. but no real insight yet..

Thoughts/comments appreciated...

Thanks

[bruce]

Followup.

So far lots of tests/no success:

To refresh:
 The goal, to be able to reattach to a remote screen session, and to
run a cmd in the remote screen session, and have the cmd return to the
calling term

Research/testing I should be able to create a remote screen session,
and then reattach to it, to run the cmd.

//--this works generates the screen session 'testname' on the remote instance
ssh crawl_user@192.81.214.49 "screen -d -m -S 'testname' "

/*
  however, can't seem to figure out how/what to use in order to run the test
  "ls -al" or an echo cmd via the remote screen session.
  -various SO articles imply one of the following should work..
  but no luck!
*/
--which of these??

ssh crawl_user@192.81.214.49 'screen -m -d -r "testname" "ls" '
ssh crawl_user@192.81.214.49 'screen  -r "testname" "ls" '

ssh -t crawl_user@192.81.214.49 'screen  -r "testname" "nohup ls &" '
--ssh -f crawl_user@192.81.214.49 'screen  -r "testname" "nohup ls &" '
ssh -t crawl_user@192.81.214.49 'screen  -r "testname" "nohup ls &"  &'

ssh -t crawl_user@192.81.214.49 'screen  -r "testname" "nohup ls >
aa.tmp  2>&1 > /dev/null " '
ssh -t crawl_user@192.81.214.49 'screen  -r "testname" -X echo "hhh" > aa.tmp '
ssh -t crawl_user@192.81.214.49 'screen  -r "testname" -X ls > aa.tmp '

On Sat, Nov 12, 2016 at 2:45 PM, bruce  wrote:
> Hey Ladies/Gents.
>
> This follows the other thread i posted over the last few weeks on
> devOPS stuff for managing groups of remote droplets/vms.
>
> My approach for now to implement clusterSSH as well as screen to be
> able to auto gen the remote droplets, and to be able to ssh into them
> to view status, as well as to track progress, and run remote processes
> with the screen env.
>
> I'm currently testing the screen function to get more familiar with
> it, and running into an issue.
>
> I generate a basic test screen session, with a name. This session is there.
>   screen -ls
> shows the session and i can pop another term, and ssh into the box,,
> and attach to the screen session
>   screen -r 'testname' gets into the session.
>
> However, when I attempt to do a simple test, to run a remote cmd
> within the remote ssh/screen env, I run into issues. I get an error in
> that the ssh/screen/cmd needs a terminal
>    -----Must be connected to a terminal.
>
> Ive tested/tried a few different iterations of the ssh/screen/ls to
> try to get this to work.
>
> //--this actually generates the screen sesstion on the remote box, no issues
> ssh crawl_user@192.81.214.49 "screen -d -m -S 'testname' "
>
> //--which of these (or something else) to remotely run ls in the
> ssh/screen session??
> --which of these??
> ssh crawl_user@192.81.214.49 'screen -m -d -r "testname" "ls" '
> ssh crawl_user@192.81.214.49 'screen  -r "testname" "ls" '
>
> ssh -t crawl_user@192.81.214.49 'screen  -r "testname" "nhup ls &" '
>   --- this almost seems to work, but the process hangs, leaving the
> user in the remote term, in other words, it doesn't run, and return to
> the calling term
>
> I've been looking at the net/goog/SO/etc.. but no real insight yet..
>
> Thoughts/comments appreciated...
>
> Thanks

[Patrick O'Callaghan]

On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> The goal, to be able to reattach to a remote screen session, and to
> run a cmd in the remote screen session, and have the cmd return to the
> calling term

Maybe take a look at expect (dnf info expect).

poc

[bruce]

I think I'm getting closer to an actual soln...

** Notice the backticks around the remote cmd to be run
 -without the ticks, the cmd doesn't appear to work

ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
/crawl_tmp/* > aa.tmp`"  '
ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"  '
ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`" & '

If the backticks are required, ok the final part of the solution is to
make the whole thing run the cmd in the screen session, but return
back to the calling term, once the screen session/cmd starts.

In other words I want the long running/remote process to start running
in the screen session and return the control to the calling term
without waiting for the completion of the process.

With the basic tests using the sleep func.. it appears that my current
attempts aren't quite there yet.

I don't want to put the remote/running cmd in the background, as that
would disable the ability to see/view the display output of the
process.

Tried to put the screen process in the background.. no luck..

Thoughts/comments???

THanks

On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
 wrote:
> On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > The goal, to be able to reattach to a remote screen session, and to
> > run a cmd in the remote screen session, and have the cmd return to the
> > calling term
>
> Maybe take a look at expect (dnf info expect).
>
> poc
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jakub Jelen]

On 11/14/2016 02:17 AM, bruce wrote:
> I think I'm getting closer to an actual soln...
>
> ** Notice the backticks around the remote cmd to be run
>   -without the ticks, the cmd doesn't appear to work
>
> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
> /crawl_tmp/* > aa.tmp`"  '
> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"  '
> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`" & '
>
> If the backticks are required, ok the final part of the solution is to
> make the whole thing run the cmd in the screen session, but return
> back to the calling term, once the screen session/cmd starts.

The backticks makes your command run in your local sub-shell, not the 
remote one.

Also if you want interactive session, you need to use -t switch to the 
ssh command.
> In other words I want the long running/remote process to start running
> in the screen session and return the control to the calling term
> without waiting for the completion of the process.
>
> With the basic tests using the sleep func.. it appears that my current
> attempts aren't quite there yet.
>
> I don't want to put the remote/running cmd in the background, as that
> would disable the ability to see/view the display output of the
> process.
>
> Tried to put the screen process in the background.. no luck..
>
> Thoughts/comments???
>
> THanks
>
> On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
>  wrote:
> > On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > > The goal, to be able to reattach to a remote screen session, and to
> > > run a cmd in the remote screen session, and have the cmd return to the
> > > calling term
> >
> > Maybe take a look at expect (dnf info expect).
> >
> > poc
> > _______________________________________________
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[bruce]

Hi Jakub

So you're saying
> > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`ls -al /crawl_tmp/* > aa.tmp`"  '

is not the correct approach to running a remote cmd in a screen
session, and that the cmd wrapped in the backticks is run on the local
machine, not the remote machine???

changing the cmd, using the "-t" or the "-f" doesn't work either.
- also tried changing the quotes wrapping the remote cmd from double
to single quotes. as I understand it, the expansion of the cmd within
the quotes, changes depending on the single or double quote used.

ssh  -t crawl_user@192.81.214.49 'screen -r "testname" -X "ls -al
/crawl_tmp/* > aa.tmp"  '
ssh  -t crawl_user@192.81.214.49 "screen -r "testname" -X 'ls -al
/crawl_tmp/* > aa.tmp'  "

So if you (or anyone else) has actual test cmds/funcs that I can
implement post, and I'll gladly test.

But for now, can't seem to find the subtle error..

Thanks

On Mon, Nov 14, 2016 at 3:05 AM, Jakub Jelen  wrote:
> On 11/14/2016 02:17 AM, bruce wrote:
> > I think I'm getting closer to an actual soln...
> >
> > ** Notice the backticks around the remote cmd to be run
> >   -without the ticks, the cmd doesn't appear to work
> >
> > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
> > /crawl_tmp/* > aa.tmp`"  '
> > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > '
> > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > & '
> >
> > If the backticks are required, ok the final part of the solution is to
> > make the whole thing run the cmd in the screen session, but return
> > back to the calling term, once the screen session/cmd starts.
>
> The backticks makes your command run in your local sub-shell, not the remote
> one.
>
> Also if you want interactive session, you need to use -t switch to the ssh
> command.
> > In other words I want the long running/remote process to start running
> > in the screen session and return the control to the calling term
> > without waiting for the completion of the process.
> >
> > With the basic tests using the sleep func.. it appears that my current
> > attempts aren't quite there yet.
> >
> > I don't want to put the remote/running cmd in the background, as that
> > would disable the ability to see/view the display output of the
> > process.
> >
> > Tried to put the screen process in the background.. no luck..
> >
> > Thoughts/comments???
> >
> > THanks
> >
> > On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
> >  wrote:
> > > On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > > > The goal, to be able to reattach to a remote screen session, and to
> > > > run a cmd in the remote screen session, and have the cmd return to the
> > > > calling term
> > >
> > > Maybe take a look at expect (dnf info expect).
> > >
> > > poc
> > > _______________________________________________
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/14/2016 03:01 AM, bruce wrote:
> Hi Jakub
>
> So you're saying
> > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`ls -al /crawl_tmp/* > aa.tmp`"  '
>
> is not the correct approach to running a remote cmd in a screen
> session, and that the cmd wrapped in the backticks is run on the local
> machine, not the remote machine???
>
> changing the cmd, using the "-t" or the "-f" doesn't work either.
> also tried changing the quotes wrapping the remote cmd from double
>
> to single quotes. as I understand it, the expansion of the cmd within
> the quotes, changes depending on the single or double quote used.
>
> ssh  -t crawl_user@192.81.214.49 'screen -r "testname" -X "ls -al
> /crawl_tmp/* > aa.tmp"  '
> ssh  -t crawl_user@192.81.214.49 "screen -r "testname" -X 'ls -al
> /crawl_tmp/* > aa.tmp'  "
>
> So if you (or anyone else) has actual test cmds/funcs that I can
> implement post, and I'll gladly test.
>
> But for now, can't seem to find the subtle error..

I think you have to specify the screen session name by prefixing it
with "-S" (the documentation is murky on this one--the "-r" should be
enough). Try:

ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -X "ls -al
/crawl_tmp/* > aa.tmp"'
> On Mon, Nov 14, 2016 at 3:05 AM, Jakub Jelen  wrote:
> > On 11/14/2016 02:17 AM, bruce wrote:
> > > I think I'm getting closer to an actual soln...
> > >
> > > ** Notice the backticks around the remote cmd to be run
> > >   -without the ticks, the cmd doesn't appear to work
> > >
> > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
> > > /crawl_tmp/* > aa.tmp`"  '
> > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > '
> > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > & '
> > >
> > > If the backticks are required, ok the final part of the solution is to
> > > make the whole thing run the cmd in the screen session, but return
> > > back to the calling term, once the screen session/cmd starts.
> >
> > The backticks makes your command run in your local sub-shell, not the remote
> > one.
> >
> > Also if you want interactive session, you need to use -t switch to the ssh
> > command.
> > > In other words I want the long running/remote process to start running
> > > in the screen session and return the control to the calling term
> > > without waiting for the completion of the process.
> > >
> > > With the basic tests using the sleep func.. it appears that my current
> > > attempts aren't quite there yet.
> > >
> > > I don't want to put the remote/running cmd in the background, as that
> > > would disable the ability to see/view the display output of the
> > > process.
> > >
> > > Tried to put the screen process in the background.. no luck..
> > >
> > > Thoughts/comments???
> > >
> > > THanks
> > >
> > > On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
> > >  wrote:
> > > > On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > > > > The goal, to be able to reattach to a remote screen session, and to
> > > > > run a cmd in the remote screen session, and have the cmd return to the
> > > > > calling term
> > > >
> > > > Maybe take a look at expect (dnf info expect).
> > > >
> > > > poc
> > > > _______________________________________________
> > > > users mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > --
> > Jakub Jelen
> > Software Engineer
> > Security Technologies
> > Red Hat
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[bruce]

Hey Rick...

Morning dude! Thanks for the reply.

I've tried a bunch of different combinations, including the one you
posted.. What seems to be happening, is that I can get it to run. The
tmp file is generated with the data but the session doesn't
immeadiately detach. It only detaches after the process completes!!

In my case, I'm looking at having 100s of digitalocean droplets
running long running processes as part of the crawler. so I need to
fire off the crawling process, on the remote droplet via SSH get it
running in the named session, and then detach, with control going back
to the calling term/process, thus minimizing the number of ongoing SSH
connects...

I've tried
ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname"   -X "`sleep 100 `"  '
ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -d   -X
"`sleep 100 `"  '

ssh  -t crawl_user@192.81.214.49 'screen  -S "testname"   -X "`sleep 100 `"  '
ssh  -t crawl_user@192.81.214.49 'screen  -S "testname" -d   -X
"`sleep 100 `"  '

and a bunch of other combinations.. also tried without the "-t" ssh attribute..

I used the sleep to see if the process was actually waiting for the
process to complete before it detached.. the "ls..... " generated the
data to show the cmd was actually running.. but it wasn't a good way
to validate the session waiting for the completion before detaching.
Changing the sleep time, verified the behaviour.

I'm missing something.. and I know it's subtle.. but I can't see it..

On Mon, Nov 14, 2016 at 1:21 PM, Rick Stevens  wrote:
> On 11/14/2016 03:01 AM, bruce wrote:
> > Hi Jakub
> >
> > So you're saying
> > > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`ls -al /crawl_tmp/* > aa.tmp`"  '
> >
> > is not the correct approach to running a remote cmd in a screen
> > session, and that the cmd wrapped in the backticks is run on the local
> > machine, not the remote machine???
> >
> > changing the cmd, using the "-t" or the "-f" doesn't work either.
> > also tried changing the quotes wrapping the remote cmd from double
> >
> > to single quotes. as I understand it, the expansion of the cmd within
> > the quotes, changes depending on the single or double quote used.
> >
> > ssh  -t crawl_user@192.81.214.49 'screen -r "testname" -X "ls -al
> > /crawl_tmp/* > aa.tmp"  '
> > ssh  -t crawl_user@192.81.214.49 "screen -r "testname" -X 'ls -al
> > /crawl_tmp/* > aa.tmp'  "
> >
> > So if you (or anyone else) has actual test cmds/funcs that I can
> > implement post, and I'll gladly test.
> >
> > But for now, can't seem to find the subtle error..
>
> I think you have to specify the screen session name by prefixing it
> with "-S" (the documentation is murky on this one--the "-r" should be
> enough). Try:
>     ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -X "ls -al
>
> /crawl_tmp/* > aa.tmp"'
> > On Mon, Nov 14, 2016 at 3:05 AM, Jakub Jelen  wrote:
> > > On 11/14/2016 02:17 AM, bruce wrote:
> > > > I think I'm getting closer to an actual soln...
> > > >
> > > > ** Notice the backticks around the remote cmd to be run
> > > >   -without the ticks, the cmd doesn't appear to work
> > > >
> > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
> > > > /crawl_tmp/* > aa.tmp`"  '
> > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > > '
> > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > > & '
> > > >
> > > > If the backticks are required, ok the final part of the solution is to
> > > > make the whole thing run the cmd in the screen session, but return
> > > > back to the calling term, once the screen session/cmd starts.
> > >
> > > The backticks makes your command run in your local sub-shell, not the remote
> > > one.
> > >
> > > Also if you want interactive session, you need to use -t switch to the ssh
> > > command.
> > > > In other words I want the long running/remote process to start running
> > > > in the screen session and return the control to the calling term
> > > > without waiting for the completion of the process.
> > > >
> > > > With the basic tests using the sleep func.. it appears that my current
> > > > attempts aren't quite there yet.
> > > >
> > > > I don't want to put the remote/running cmd in the background, as that
> > > > would disable the ability to see/view the display output of the
> > > > process.
> > > >
> > > > Tried to put the screen process in the background.. no luck..
> > > >
> > > > Thoughts/comments???
> > > >
> > > > THanks
> > > >
> > > > On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
> > > >  wrote:
> > > > > On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > > > > > The goal, to be able to reattach to a remote screen session, and to
> > > > > > run a cmd in the remote screen session, and have the cmd return to the
> > > > > > calling term
> > > > >
> > > > > Maybe take a look at expect (dnf info expect).
> > > > >
> > > > > poc
> > > > > _______________________________________________
> > > > > users mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > users mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > --
> > > Jakub Jelen
> > > Software Engineer
> > > Security Technologies
> > > Red Hat
> > >
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> --
> Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>                                                                -
> First Law of Work:                                              -
> If you can't get it done in the first 24 hours, work nights.    -
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/14/2016 11:13 AM, bruce wrote:
> Hey Rick...
>
> Morning dude! Thanks for the reply.
>
> I've tried a bunch of different combinations, including the one you
> posted.. What seems to be happening, is that I can get it to run. The
> tmp file is generated with the data but the session doesn't
> immeadiately detach. It only detaches after the process completes!!
>
> In my case, I'm looking at having 100s of digitalocean droplets
> running long running processes as part of the crawler. so I need to
> fire off the crawling process, on the remote droplet via SSH get it
> running in the named session, and then detach, with control going back
> to the calling term/process, thus minimizing the number of ongoing SSH
> connects...
>
> I've tried
> ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname"   -X "`sleep 100 `"  '
> ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -d   -X
> "`sleep 100 `"  '
>
> ssh  -t crawl_user@192.81.214.49 'screen  -S "testname"   -X "`sleep 100 `"  '
> ssh  -t crawl_user@192.81.214.49 'screen  -S "testname" -d   -X
> "`sleep 100 `"  '
>
> and a bunch of other combinations.. also tried without the "-t" ssh attribute..
>
> I used the sleep to see if the process was actually waiting for the
> process to complete before it detached.. the "ls..... " generated the
> data to show the cmd was actually running.. but it wasn't a good way
> to validate the session waiting for the completion before detaching.
> Changing the sleep time, verified the behaviour.
>
> I'm missing something.. and I know it's subtle.. but I can't see it..

Instead of "-d" try "-D" (power detach).
> On Mon, Nov 14, 2016 at 1:21 PM, Rick Stevens  wrote:
> > On 11/14/2016 03:01 AM, bruce wrote:
> > > Hi Jakub
> > >
> > > So you're saying
> > > > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`ls -al /crawl_tmp/* > aa.tmp`"  '
> > >
> > > is not the correct approach to running a remote cmd in a screen
> > > session, and that the cmd wrapped in the backticks is run on the local
> > > machine, not the remote machine???
> > >
> > > changing the cmd, using the "-t" or the "-f" doesn't work either.
> > > also tried changing the quotes wrapping the remote cmd from double
> > >
> > > to single quotes. as I understand it, the expansion of the cmd within
> > > the quotes, changes depending on the single or double quote used.
> > >
> > > ssh  -t crawl_user@192.81.214.49 'screen -r "testname" -X "ls -al
> > > /crawl_tmp/* > aa.tmp"  '
> > > ssh  -t crawl_user@192.81.214.49 "screen -r "testname" -X 'ls -al
> > > /crawl_tmp/* > aa.tmp'  "
> > >
> > > So if you (or anyone else) has actual test cmds/funcs that I can
> > > implement post, and I'll gladly test.
> > >
> > > But for now, can't seem to find the subtle error..
> >
> > I think you have to specify the screen session name by prefixing it
> > with "-S" (the documentation is murky on this one--the "-r" should be
> > enough). Try:
> >     ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -X "ls -al
> >
> > /crawl_tmp/* > aa.tmp"'
> > > On Mon, Nov 14, 2016 at 3:05 AM, Jakub Jelen  wrote:
> > > > On 11/14/2016 02:17 AM, bruce wrote:
> > > > > I think I'm getting closer to an actual soln...
> > > > >
> > > > > ** Notice the backticks around the remote cmd to be run
> > > > >   -without the ticks, the cmd doesn't appear to work
> > > > >
> > > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
> > > > > /crawl_tmp/* > aa.tmp`"  '
> > > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > > > '
> > > > > ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
> > > > > & '
> > > > >
> > > > > If the backticks are required, ok the final part of the solution is to
> > > > > make the whole thing run the cmd in the screen session, but return
> > > > > back to the calling term, once the screen session/cmd starts.
> > > >
> > > > The backticks makes your command run in your local sub-shell, not the remote
> > > > one.
> > > >
> > > > Also if you want interactive session, you need to use -t switch to the ssh
> > > > command.
> > > > > In other words I want the long running/remote process to start running
> > > > > in the screen session and return the control to the calling term
> > > > > without waiting for the completion of the process.
> > > > >
> > > > > With the basic tests using the sleep func.. it appears that my current
> > > > > attempts aren't quite there yet.
> > > > >
> > > > > I don't want to put the remote/running cmd in the background, as that
> > > > > would disable the ability to see/view the display output of the
> > > > > process.
> > > > >
> > > > > Tried to put the screen process in the background.. no luck..
> > > > >
> > > > > Thoughts/comments???
> > > > >
> > > > > THanks
> > > > >
> > > > > On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
> > > > >  wrote:
> > > > > > On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
> > > > > > >
> > > > > > >   The goal, to be able to reattach to a remote screen session, and to
> > > > > > > run a cmd in the remote screen session, and have the cmd return to the
> > > > > > > calling term
> > > > > >
> > > > > > Maybe take a look at expect (dnf info expect).
> > > > > >
> > > > > > poc
> > > > > > _______________________________________________
> > > > > > users mailing list -- [e-mail]
> > > > > > To unsubscribe send an email to [e-mail]
> > > > >
> > > > > users mailing list -- [e-mail]
> > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > --
> > > > Jakub Jelen
> > > > Software Engineer
> > > > Security Technologies
> > > > Red Hat
> > > >
> > > > users mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > --
> > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> >                                                                -
> > First Law of Work:                                              -
> > If you can't get it done in the first 24 hours, work nights.    -
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Tom Horsley]

On Mon, 14 Nov 2016 14:13:48 -0500
bruce wrote:
> It only detaches after the process completes!!

ssh goes to fantastic amounts of trouble to invent
ridiculous file descriptors it can wait on till
they close (specifically to prevent you from
exiting an ssh session and leaving anything running).

I use the bg-dammit program I wrote to actually
for Gosh sakes background stuff. You can find the source
on this web page:

http://tomhorsley.com/game/Mjolnir.html

(you might need to tweak things like debug
logging code that has hard coded file paths :-).

[Gordon Messmer]

On 11/14/2016 12:01 PM, Tom Horsley wrote:
> ssh goes to fantastic amounts of trouble to invent
> ridiculous file descriptors it can wait on till
> they close

No it doesn't.  ssh has a simple, well-defined behavior.  It doesn't 
create non-standard (read "ridiculous") file descriptors. If you're 
having trouble detaching, it's because you have a program running that's 
still attached to the controlling tty.  If you've launched a program 
that should have disconnected and hasn't, it's that program's fault.  
The process for daemonizing is described in excruciating detail here, 
among other programming guides:

http://cjh.polyplex.org/software/daemon.pdf

If you have software that doesn't work correctly, you can use the 
"daemonize" program to ensure it disconnects from the tty properly:

https://linux.die.net/man/1/daemonize

[bruce]

hey guys...

got a much simpler issue/question...

I thought I had been running the remote cmd within the screen named
session.. upon further testing.. I may not have actually been running
it in the screen session.. perhaps outside of the session..

I think this works....

//--fire up the named screen session..
ssh crawl_user@192.81.214.49 "screen -d -m -S 'testname' "

//fire up the "long running cmd....
ssh  -t crawl_user@192.81.214.49  "screen -r -S testname  -X stuff
'sleep 60'$(echo -ne '\015')  "

i've tested this with sleeping of different times, as well as diff sys
commands.. it seems to work ok...

I'll do more testing of course!

I've been able to do the proc tbl (ps) to see that the cmds are being
run.. and in checking the screen/session.. it is definitely detached.

As a check to ensure that this really works... I did a sleep test,
without the echo -ne '\015' -- which generates the newline..

This checked out that the screen session was attached...

So, I think this is ok...

Thoughts/Comments

On Mon, Nov 14, 2016 at 3:01 PM, Tom Horsley  wrote:
> On Mon, 14 Nov 2016 14:13:48 -0500
> bruce wrote:
> > It only detaches after the process completes!!
>
> ssh goes to fantastic amounts of trouble to invent
> ridiculous file descriptors it can wait on till
> they close (specifically to prevent you from
> exiting an ssh session and leaving anything running).
>
> I use the bg-dammit program I wrote to actually
> for Gosh sakes background stuff. You can find the source
> on this web page:
>
> http://tomhorsley.com/game/Mjolnir.html
>
> (you might need to tweak things like debug
> logging code that has hard coded file paths :-).
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]