ssh/screen -- cmdline vs php

[bruce]

Hey guys..

I crafted a test php app to generate the test cmdline to ssh into the
remote box, attach to the screen, and fire off the testApp...

This works as expected from the cmdline...

I
   su - crawl_user,
 then run the cmd, take a look on another term, that's set to the
ipAddress. When I attach to the screen.. I see the app running..
Checking the procTbl shows the app running as well...

However....

when I run the cmd from a test php... using backticks.. the remote
ssh/screen/app isn't run...

Any pointers on what I can look at to debug this..

the actual cmd that works on the cmdline::

ssh  -t crawl_user@162.243.166.31  "screen -r crawlSession  -X stuff
'/crawl_tmp/startCollegeCrawl_test_bycol.php   --crawlDir /crawl_tmp
--nfsDir /cloud_nfs  --nfsFetchDir /cloud_nfs_fetch  --colName
austincc_0'$(echo -ne '\015')  "

the test php that generates the above cmd...

//--run the bycol for the college, using the ipAddress..
    $scmd="ssh  -t crawl_user@".$bycol_ip_list[$cnt].'  "screen -r
crawlSession  -X stuff ';
    $scmd=$scmd."'/crawl_tmp/startCollegeCrawl_test_bycol.php
--crawlDir /crawl_tmp  ";
    $scmd=$scmd."--nfsDir /cloud_nfs  --nfsFetchDir /cloud_nfs_fetch  ";
    $scmd=$scmd."--colName ".$d."'$(echo -ne '\015')  ".'"';

print "bycol cmd .. ".$scmd."\n";

$scmd=`$scmd`;
    print " stop..bycol sleeping prior to starting..\n";
    exit();

thanks....

[Samuel Sieb]

On 11/16/2016 05:58 PM, bruce wrote:
> when I run the cmd from a test php... using backticks.. the remote
> ssh/screen/app isn't run...

I suspect that when run that way, the process doesn't have a terminal so 
some things might not work.  Also, assuming you're running the php from 
a web server, the web server user (most likely apache) might not have 
permission to create network connections.  Check for selinux errors. 
Can you tell how far it gets?  Does it start the ssh process?  Does the 
ssh process connect?  etc.

[bruce]

aha!!

ok.. more testing, more insight into whats going on...

the basic setup
 client box (boxA) - running the screen session 'test'

local box (boxB) - invokes the ssh/screen/remote app

test I)
-running the test app on boxB that invokes the ssh/screen remote app
  works if the test screen session on boxA is detached!!!
  --the screen/remote is created by screen -r 'test' ...

however, if i attach the test screen session on boxA
  using screen -r 'test'
and then run the test app on boxB,
  --using ssh -- screen -r 'test' ...
  to run the remote within the named screen session...

the process doesn't work.. .
  -now, if I change the test app on BoxB to use
  --using ssh -- screen -x 'test' ...    <<<<<<

then this works, even though the 'test' screen session is already attached!!

ok.. this more or less makes sense..

So, it appears that I need some way of attaching to the named 'test' screen
 session regardless of the session being attached/detached..

I can't see any attribute for screen that allows that.. but I might
simply be missing something..

Thoughts/comments..

thanks

On Thu, Nov 17, 2016 at 1:44 AM, Samuel Sieb  wrote:
> On 11/16/2016 05:58 PM, bruce wrote:
> > when I run the cmd from a test php... using backticks.. the remote
> > ssh/screen/app isn't run...
>
> I suspect that when run that way, the process doesn't have a terminal so
> some things might not work.  Also, assuming you're running the php from a
> web server, the web server user (most likely apache) might not have
> permission to create network connections.  Check for selinux errors. Can you
> tell how far it gets?  Does it start the ssh process?  Does the ssh process
> connect?  etc.
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/17/2016 07:14 AM, bruce wrote:
> aha!!
>
> ok.. more testing, more insight into whats going on...
>
> the basic setup
>  client box (boxA) - running the screen session 'test'
>
> local box (boxB) - invokes the ssh/screen/remote app
>
> test I)
> -running the test app on boxB that invokes the ssh/screen remote app
>   works if the test screen session on boxA is detached!!!
>   --the screen/remote is created by screen -r 'test' ...
>
> however, if i attach the test screen session on boxA
>   using screen -r 'test'
> and then run the test app on boxB,
>   --using ssh -- screen -r 'test' ...
>   to run the remote within the named screen session...
>
> the process doesn't work.. .
>   -now, if I change the test app on BoxB to use
>   --using ssh -- screen -x 'test' ...    <<<<<<
>
> then this works, even though the 'test' screen session is already attached!!
>
> ok.. this more or less makes sense..
>
> So, it appears that I need some way of attaching to the named 'test' screen
>  session regardless of the session being attached/detached..
>
> I can't see any attribute for screen that allows that.. but I might
> simply be missing something..

Your description is very difficult to follow for me. Perhaps the
formatting is mucked up.

To run a process in the background WITHOUT attaching to the screen
session, launch the process using

screen -d -m -S sessname 'script parm1 parm2'

This will cause screen to create a session named "sessname" and launch
the script WITHOUT creating an attached session. We use this all the
time to launch long running processes at boot time that require a
console.

If you want to attach to the session thus launched, use

screen -r sessname

Note that if you want to see the output of a screen session, you must
attach to it OR you must have its output logged via the "-L" option (or
by using "CTRL-A H" in the session) and you can then "tail -f" the log
file.

If you want to run in what is called "multi display" mode, then

screen -x -r sessname

should do it. The "-x" option allows you to attach a second (or third,
or fourth) terminal to a session that already is attached to give you
another terminal to communicate with it. You can think of it as a form
of "screen sharing".

I won't swear to it but I think if you use "-x" on a session that
DOESN'T already have an attached terminal, then the "-x" is ignored and
you attach normally (requiring the "CTRL-A d" to detach and leave the
session running).
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-          Consciousness: that annoying time between naps.           -
----------------------------------------------------------------------

[bruce]

Hey Rick...

More testing....

Not sure if you can use the "-x -r" attributes at the same time.. I'll
def check it though.

As a kludge/workaround.. I did a quick screen -ls to check if the
session was attached/detached, and implemented the remote app based on
that.. As I said a kludge ,but it works for now..

As to the "real issue" of why I was getting weird behaviours..

I had somehow managed to have an existing screen session with 'test'..
in my testing, I created a 2nd session with 'test', and then when I
was doing the remote app -- using the name 'test'.. it blew up/didn't
run...

I stuck a check to not create the session name, if it already exists..
now running again...

Once I get all of this working.. I'll jump to the clusterSSH.. to
check that out...

If both parts look 'good'...

This thing is getting close to being able to fire up to go fetch data
from the 300-400 colleges..

I know.. relatively trivial when you look at it..

On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> On 11/17/2016 07:14 AM, bruce wrote:
> > aha!!
> >
> > ok.. more testing, more insight into whats going on...
> >
> > the basic setup
> >  client box (boxA) - running the screen session 'test'
> >
> > local box (boxB) - invokes the ssh/screen/remote app
> >
> > test I)
> > -running the test app on boxB that invokes the ssh/screen remote app
> >   works if the test screen session on boxA is detached!!!
> >   --the screen/remote is created by screen -r 'test' ...
> >
> > however, if i attach the test screen session on boxA
> >   using screen -r 'test'
> > and then run the test app on boxB,
> >   --using ssh -- screen -r 'test' ...
> >   to run the remote within the named screen session...
> >
> > the process doesn't work.. .
> >   -now, if I change the test app on BoxB to use
> >   --using ssh -- screen -x 'test' ...    <<<<<<
> >
> > then this works, even though the 'test' screen session is already attached!!
> >
> > ok.. this more or less makes sense..
> >
> > So, it appears that I need some way of attaching to the named 'test' screen
> >  session regardless of the session being attached/detached..
> >
> > I can't see any attribute for screen that allows that.. but I might
> > simply be missing something..
>
> Your description is very difficult to follow for me. Perhaps the
> formatting is mucked up.
>
> To run a process in the background WITHOUT attaching to the screen
> session, launch the process using
>     screen -d -m -S sessname 'script parm1 parm2'
>
> This will cause screen to create a session named "sessname" and launch
> the script WITHOUT creating an attached session. We use this all the
> time to launch long running processes at boot time that require a
> console.
>
> If you want to attach to the session thus launched, use
>     screen -r sessname
>
> Note that if you want to see the output of a screen session, you must
> attach to it OR you must have its output logged via the "-L" option (or
> by using "CTRL-A H" in the session) and you can then "tail -f" the log
> file.
>
> If you want to run in what is called "multi display" mode, then
>     screen -x -r sessname
>
> should do it. The "-x" option allows you to attach a second (or third,
> or fourth) terminal to a session that already is attached to give you
> another terminal to communicate with it. You can think of it as a form
> of "screen sharing".
>
> I won't swear to it but I think if you use "-x" on a session that
> DOESN'T already have an attached terminal, then the "-x" is ignored and
> you attach normally (requiring the "CTRL-A d" to detach and leave the
> session running).
> Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>                                                                -
>      Consciousness: that annoying time between naps.           -
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/17/2016 09:47 AM, bruce wrote:
> Hey Rick...
>
> More testing....
>
> Not sure if you can use the "-x -r" attributes at the same time.. I'll
> def check it though.
>
> As a kludge/workaround.. I did a quick screen -ls to check if the
> session was attached/detached, and implemented the remote app based on
> that.. As I said a kludge ,but it works for now..
>
> As to the "real issue" of why I was getting weird behaviours..
>
> I had somehow managed to have an existing screen session with 'test'..
> in my testing, I created a 2nd session with 'test', and then when I
> was doing the remote app -- using the name 'test'.. it blew up/didn't
> run...
>
> I stuck a check to not create the session name, if it already exists..
> now running again...
>
> Once I get all of this working.. I'll jump to the clusterSSH.. to
> check that out...
>
> If both parts look 'good'...
>
> This thing is getting close to being able to fire up to go fetch data
> from the 300-400 colleges..
>
> I know.. relatively trivial when you look at it..

NEVER say it's "trivial". Engineering criterium #7 clearly states:

Build no mechanism simply if a way can be found to make it
    complex and wonderful. This also justifies your existence and
    paycheck.

Phelps' corollary to that states:

If it was easy, everyone would do it.
> On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > On 11/17/2016 07:14 AM, bruce wrote:
> > > aha!!
> > >
> > > ok.. more testing, more insight into whats going on...
> > >
> > > the basic setup
> > >  client box (boxA) - running the screen session 'test'
> > >
> > > local box (boxB) - invokes the ssh/screen/remote app
> > >
> > > test I)
> > > -running the test app on boxB that invokes the ssh/screen remote app
> > >   works if the test screen session on boxA is detached!!!
> > >   --the screen/remote is created by screen -r 'test' ...
> > >
> > > however, if i attach the test screen session on boxA
> > >   using screen -r 'test'
> > > and then run the test app on boxB,
> > >   --using ssh -- screen -r 'test' ...
> > >   to run the remote within the named screen session...
> > >
> > > the process doesn't work.. .
> > >   -now, if I change the test app on BoxB to use
> > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > >
> > > then this works, even though the 'test' screen session is already attached!!
> > >
> > > ok.. this more or less makes sense..
> > >
> > > So, it appears that I need some way of attaching to the named 'test' screen
> > >  session regardless of the session being attached/detached..
> > >
> > > I can't see any attribute for screen that allows that.. but I might
> > > simply be missing something..
> >
> > Your description is very difficult to follow for me. Perhaps the
> > formatting is mucked up.
> >
> > To run a process in the background WITHOUT attaching to the screen
> > session, launch the process using
> >     screen -d -m -S sessname 'script parm1 parm2'
> >
> > This will cause screen to create a session named "sessname" and launch
> > the script WITHOUT creating an attached session. We use this all the
> > time to launch long running processes at boot time that require a
> > console.
> >
> > If you want to attach to the session thus launched, use
> >     screen -r sessname
> >
> > Note that if you want to see the output of a screen session, you must
> > attach to it OR you must have its output logged via the "-L" option (or
> > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > file.
> >
> > If you want to run in what is called "multi display" mode, then
> >     screen -x -r sessname
> >
> > should do it. The "-x" option allows you to attach a second (or third,
> > or fourth) terminal to a session that already is attached to give you
> > another terminal to communicate with it. You can think of it as a form
> > of "screen sharing".
> >
> > I won't swear to it but I think if you use "-x" on a session that
> > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > session running).

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-        Is it progress if a cannibal uses a knife and fork?         -
-                                  -- Stanislaw J. Lec               -
----------------------------------------------------------------------

[bruce]

trivial it is!!

My inability to solve this in a few mins, says more about me, than the
difficulty of the prob!

The following:
ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession

will attach to a detached named screen session.. the term pops up with
the attached screen from the SSH.. This is verified by having a sep
term, where I do a screen -ls and see that the screen is "Attached".

However, the term, shows the screen/term/cmdline prompt. If I manually
enter "CRTL-A d" the process, detaches the screen and the term returns
to the calling env...

My question!!

How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?

When in the screen session at the term/cursor/cmdline prompt I tried to enter:
$ printf '\001'
$ printf '\004'

Which I saw somewhere was the process to generate the "Ctrl-a d"
sequence.. but this didn't work.

I've also seen somewhere, where the ^Ad was the sequence again ,no luck..

Here's why I'm asking...

I created a test script (php) to fire off the actual remote cmd to be
run in the screen session via SSH.. It doesn't work when it gets run..
The test script fires off the screen, with the attribute changed being
'r' or 'x' based on the attach/detach of the screen..

However, if I go into the target vm and then attach/detach the screen
(which should put the screen session back to the initial state), and I
then run the test app, The app runs correctly.. and the remote process
runs..

So, I want to test how to simulate/perform the same process in a test script.

Thanks..

On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> On 11/17/2016 09:47 AM, bruce wrote:
> > Hey Rick...
> >
> > More testing....
> >
> > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > def check it though.
> >
> > As a kludge/workaround.. I did a quick screen -ls to check if the
> > session was attached/detached, and implemented the remote app based on
> > that.. As I said a kludge ,but it works for now..
> >
> > As to the "real issue" of why I was getting weird behaviours..
> >
> > I had somehow managed to have an existing screen session with 'test'..
> > in my testing, I created a 2nd session with 'test', and then when I
> > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > run...
> >
> > I stuck a check to not create the session name, if it already exists..
> > now running again...
> >
> > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > check that out...
> >
> > If both parts look 'good'...
> >
> > This thing is getting close to being able to fire up to go fetch data
> > from the 300-400 colleges..
> >
> > I know.. relatively trivial when you look at it..
>
> NEVER say it's "trivial". Engineering criterium #7 clearly states:
>     Build no mechanism simply if a way can be found to make it
>     complex and wonderful. This also justifies your existence and
>     paycheck.
>
> Phelps' corollary to that states:
>     If it was easy, everyone would do it.
>
> > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > aha!!
> > > >
> > > > ok.. more testing, more insight into whats going on...
> > > >
> > > > the basic setup
> > > >  client box (boxA) - running the screen session 'test'
> > > >
> > > > local box (boxB) - invokes the ssh/screen/remote app
> > > >
> > > > test I)
> > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > >   works if the test screen session on boxA is detached!!!
> > > >   --the screen/remote is created by screen -r 'test' ...
> > > >
> > > > however, if i attach the test screen session on boxA
> > > >   using screen -r 'test'
> > > > and then run the test app on boxB,
> > > >   --using ssh -- screen -r 'test' ...
> > > >   to run the remote within the named screen session...
> > > >
> > > > the process doesn't work.. .
> > > >   -now, if I change the test app on BoxB to use
> > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > >
> > > > then this works, even though the 'test' screen session is already attached!!
> > > >
> > > > ok.. this more or less makes sense..
> > > >
> > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > >  session regardless of the session being attached/detached..
> > > >
> > > > I can't see any attribute for screen that allows that.. but I might
> > > > simply be missing something..
> > >
> > > Your description is very difficult to follow for me. Perhaps the
> > > formatting is mucked up.
> > >
> > > To run a process in the background WITHOUT attaching to the screen
> > > session, launch the process using
> > >     screen -d -m -S sessname 'script parm1 parm2'
> > >
> > > This will cause screen to create a session named "sessname" and launch
> > > the script WITHOUT creating an attached session. We use this all the
> > > time to launch long running processes at boot time that require a
> > > console.
> > >
> > > If you want to attach to the session thus launched, use
> > >     screen -r sessname
> > >
> > > Note that if you want to see the output of a screen session, you must
> > > attach to it OR you must have its output logged via the "-L" option (or
> > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > file.
> > >
> > > If you want to run in what is called "multi display" mode, then
> > >     screen -x -r sessname
> > >
> > > should do it. The "-x" option allows you to attach a second (or third,
> > > or fourth) terminal to a session that already is attached to give you
> > > another terminal to communicate with it. You can think of it as a form
> > > of "screen sharing".
> > >
> > > I won't swear to it but I think if you use "-x" on a session that
> > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > session running).
> Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
>                                                                -
>    Is it progress if a cannibal uses a knife and fork?         -
>                              -- Stanislaw J. Lec               -
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/18/2016 06:15 AM, bruce wrote:
> trivial it is!!
>
> My inability to solve this in a few mins, says more about me, than the
> difficulty of the prob!
>
> The following:
> ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
>
> will attach to a detached named screen session.. the term pops up with
> the attached screen from the SSH.. This is verified by having a sep
> term, where I do a screen -ls and see that the screen is "Attached".
>
> However, the term, shows the screen/term/cmdline prompt. If I manually
> enter "CRTL-A d" the process, detaches the screen and the term returns
> to the calling env...
>
> My question!!
>
> How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
>
> When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> $ printf '\001'
> $ printf '\004'
> Which I saw somewhere was the process to generate the "Ctrl-a d"
> sequence.. but this didn't work.

"printf '\004'" generates a CTRL-D, not a "d". I believe you want:

$ printf '\001d'

If you want it all in octal:

$ printf '\001\144'

It's easier to do in hex, since CTRL just removes the 0x40 bit from the
character, so:

$ printf '\x01d'  (mix of hex and ASCII) OR
    $ printf '\x01\x64' (all hex)
> I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
>
> Here's why I'm asking...
>
> I created a test script (php) to fire off the actual remote cmd to be
> run in the screen session via SSH.. It doesn't work when it gets run..
> The test script fires off the screen, with the attribute changed being
> 'r' or 'x' based on the attach/detach of the screen..
>
> However, if I go into the target vm and then attach/detach the screen
> (which should put the screen session back to the initial state), and I
> then run the test app, The app runs correctly.. and the remote process
> runs..
>
> So, I want to test how to simulate/perform the same process in a test script.
>
> Thanks..
>
> On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > On 11/17/2016 09:47 AM, bruce wrote:
> > > Hey Rick...
> > >
> > > More testing....
> > >
> > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > def check it though.
> > >
> > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > session was attached/detached, and implemented the remote app based on
> > > that.. As I said a kludge ,but it works for now..
> > >
> > > As to the "real issue" of why I was getting weird behaviours..
> > >
> > > I had somehow managed to have an existing screen session with 'test'..
> > > in my testing, I created a 2nd session with 'test', and then when I
> > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > run...
> > >
> > > I stuck a check to not create the session name, if it already exists..
> > > now running again...
> > >
> > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > check that out...
> > >
> > > If both parts look 'good'...
> > >
> > > This thing is getting close to being able to fire up to go fetch data
> > > from the 300-400 colleges..
> > >
> > > I know.. relatively trivial when you look at it..
> >
> > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> >     Build no mechanism simply if a way can be found to make it
> >     complex and wonderful. This also justifies your existence and
> >     paycheck.
> >
> > Phelps' corollary to that states:
> >     If it was easy, everyone would do it.
> >
> > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > aha!!
> > > > >
> > > > > ok.. more testing, more insight into whats going on...
> > > > >
> > > > > the basic setup
> > > > >  client box (boxA) - running the screen session 'test'
> > > > >
> > > > > local box (boxB) - invokes the ssh/screen/remote app
> > > > >
> > > > > test I)
> > > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > > >   works if the test screen session on boxA is detached!!!
> > > > >   --the screen/remote is created by screen -r 'test' ...
> > > > >
> > > > > however, if i attach the test screen session on boxA
> > > > >   using screen -r 'test'
> > > > > and then run the test app on boxB,
> > > > >   --using ssh -- screen -r 'test' ...
> > > > >   to run the remote within the named screen session...
> > > > >
> > > > > the process doesn't work.. .
> > > > >   -now, if I change the test app on BoxB to use
> > > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > >
> > > > > then this works, even though the 'test' screen session is already attached!!
> > > > >
> > > > > ok.. this more or less makes sense..
> > > > >
> > > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > > >  session regardless of the session being attached/detached..
> > > > >
> > > > > I can't see any attribute for screen that allows that.. but I might
> > > > > simply be missing something..
> > > >
> > > > Your description is very difficult to follow for me. Perhaps the
> > > > formatting is mucked up.
> > > >
> > > > To run a process in the background WITHOUT attaching to the screen
> > > > session, launch the process using
> > > >     screen -d -m -S sessname 'script parm1 parm2'
> > > >
> > > > This will cause screen to create a session named "sessname" and launch
> > > > the script WITHOUT creating an attached session. We use this all the
> > > > time to launch long running processes at boot time that require a
> > > > console.
> > > >
> > > > If you want to attach to the session thus launched, use
> > > >     screen -r sessname
> > > >
> > > > Note that if you want to see the output of a screen session, you must
> > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > file.
> > > >
> > > > If you want to run in what is called "multi display" mode, then
> > > >     screen -x -r sessname
> > > >
> > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > or fourth) terminal to a session that already is attached to give you
> > > > another terminal to communicate with it. You can think of it as a form
> > > > of "screen sharing".
> > > >
> > > > I won't swear to it but I think if you use "-x" on a session that
> > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > session running).
> > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> >                                                                -
> >    Is it progress if a cannibal uses a knife and fork?         -
> >                              -- Stanislaw J. Lec               -
> >
> > 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]

hmm...

Think I resolved the issue of the ctrl-a d -- sequence, It appears
screen -X allows for the use of tags, so the "detach" appears to be a
substitute for the ctrl-A d sequence..

However, I'm still flumoxed on how to run a background process on the remote vm.

The following "should" work, but it doesn''t

ssh  -t crawl_user@159.203.185.29  "sh -c 'nohup screen -rD -S crawlSession &'"

I've also tried various combinations:

ssh  -t crawl_user@159.203.185.29  "'nohup screen -rD -S crawlSession &'"
ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession &"

The goal, to test if I can actually fire up/simulate the manual
process that you get when you do

ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession"

Which displays the screen session, and also has the actual "screen
-rD..." process in the procTBL..

thanks...

On Fri, Nov 18, 2016 at 9:15 AM, bruce  wrote:
> trivial it is!!
>
> My inability to solve this in a few mins, says more about me, than the
> difficulty of the prob!
>
> The following:
> ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
>
> will attach to a detached named screen session.. the term pops up with
> the attached screen from the SSH.. This is verified by having a sep
> term, where I do a screen -ls and see that the screen is "Attached".
>
> However, the term, shows the screen/term/cmdline prompt. If I manually
> enter "CRTL-A d" the process, detaches the screen and the term returns
> to the calling env...
>
> My question!!
>
> How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
>
> When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> $ printf '\001'
> $ printf '\004'
>
> Which I saw somewhere was the process to generate the "Ctrl-a d"
> sequence.. but this didn't work.
>
> I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
>
> Here's why I'm asking...
>
> I created a test script (php) to fire off the actual remote cmd to be
> run in the screen session via SSH.. It doesn't work when it gets run..
> The test script fires off the screen, with the attribute changed being
> 'r' or 'x' based on the attach/detach of the screen..
>
> However, if I go into the target vm and then attach/detach the screen
> (which should put the screen session back to the initial state), and I
> then run the test app, The app runs correctly.. and the remote process
> runs..
>
> So, I want to test how to simulate/perform the same process in a test script.
>
> Thanks..
>
> On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > On 11/17/2016 09:47 AM, bruce wrote:
> > > Hey Rick...
> > >
> > > More testing....
> > >
> > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > def check it though.
> > >
> > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > session was attached/detached, and implemented the remote app based on
> > > that.. As I said a kludge ,but it works for now..
> > >
> > > As to the "real issue" of why I was getting weird behaviours..
> > >
> > > I had somehow managed to have an existing screen session with 'test'..
> > > in my testing, I created a 2nd session with 'test', and then when I
> > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > run...
> > >
> > > I stuck a check to not create the session name, if it already exists..
> > > now running again...
> > >
> > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > check that out...
> > >
> > > If both parts look 'good'...
> > >
> > > This thing is getting close to being able to fire up to go fetch data
> > > from the 300-400 colleges..
> > >
> > > I know.. relatively trivial when you look at it..
> >
> > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> >     Build no mechanism simply if a way can be found to make it
> >     complex and wonderful. This also justifies your existence and
> >     paycheck.
> >
> > Phelps' corollary to that states:
> >     If it was easy, everyone would do it.
> >
> > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > aha!!
> > > > >
> > > > > ok.. more testing, more insight into whats going on...
> > > > >
> > > > > the basic setup
> > > > >  client box (boxA) - running the screen session 'test'
> > > > >
> > > > > local box (boxB) - invokes the ssh/screen/remote app
> > > > >
> > > > > test I)
> > > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > > >   works if the test screen session on boxA is detached!!!
> > > > >   --the screen/remote is created by screen -r 'test' ...
> > > > >
> > > > > however, if i attach the test screen session on boxA
> > > > >   using screen -r 'test'
> > > > > and then run the test app on boxB,
> > > > >   --using ssh -- screen -r 'test' ...
> > > > >   to run the remote within the named screen session...
> > > > >
> > > > > the process doesn't work.. .
> > > > >   -now, if I change the test app on BoxB to use
> > > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > >
> > > > > then this works, even though the 'test' screen session is already attached!!
> > > > >
> > > > > ok.. this more or less makes sense..
> > > > >
> > > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > > >  session regardless of the session being attached/detached..
> > > > >
> > > > > I can't see any attribute for screen that allows that.. but I might
> > > > > simply be missing something..
> > > >
> > > > Your description is very difficult to follow for me. Perhaps the
> > > > formatting is mucked up.
> > > >
> > > > To run a process in the background WITHOUT attaching to the screen
> > > > session, launch the process using
> > > >     screen -d -m -S sessname 'script parm1 parm2'
> > > >
> > > > This will cause screen to create a session named "sessname" and launch
> > > > the script WITHOUT creating an attached session. We use this all the
> > > > time to launch long running processes at boot time that require a
> > > > console.
> > > >
> > > > If you want to attach to the session thus launched, use
> > > >     screen -r sessname
> > > >
> > > > Note that if you want to see the output of a screen session, you must
> > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > file.
> > > >
> > > > If you want to run in what is called "multi display" mode, then
> > > >     screen -x -r sessname
> > > >
> > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > or fourth) terminal to a session that already is attached to give you
> > > > another terminal to communicate with it. You can think of it as a form
> > > > of "screen sharing".
> > > >
> > > > I won't swear to it but I think if you use "-x" on a session that
> > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > session running).
> > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> >                                                                -
> >    Is it progress if a cannibal uses a knife and fork?         -
> >                              -- Stanislaw J. Lec               -
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[bruce]

Good lord!

3 days later.. give or take.. still haven't gotten this to where it "works"..

Here's what I'm seeing and what I think is happening.

In my case, I want to start up a base instance/vm with a screen
session already defined, but the session is detached. The user that
created/started screen is "fred".

On the base vm, I can log in, and attach to the screen session, and
checking a sep login, shows the screen is attached, no prob.

My need/goal, is to be able to have an external script/py/etc.. that
fires off a remote app, to be run in the screen, using the ssh/screen
process. In theory, should be a breeze:

-Just submit the ssh to the vm, and feed the screen cmd to run an app,
should work!

-nope!

The cmdline cmd should be similar to:
ssh  -t crawl_user@159.203.185.29  "screen -D -R -S crawlSession  -X
stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "

Looking at the vm before running, it appears this should work, as the
screen is detached. But, this doesn't work...

Now, if I go in the vm, and attach to the screen, and then change the
screen attribute to "-x" from -D -R" it works..

So, I can see a bit of progress, but I've got questions, as to why
this won't work with a vm that's hasn't been attached.

Oh, just noticed, if I go in the vm attach and detach.. then the
initial cmd works..

WTH!!!

thanks

On Fri, Nov 18, 2016 at 12:51 PM, bruce  wrote:
> hmm...
>
> Think I resolved the issue of the ctrl-a d -- sequence, It appears
> screen -X allows for the use of tags, so the "detach" appears to be a
> substitute for the ctrl-A d sequence..
>
> However, I'm still flumoxed on how to run a background process on the remote vm.
>
> The following "should" work, but it doesn''t
>
> ssh  -t crawl_user@159.203.185.29  "sh -c 'nohup screen -rD -S crawlSession &'"
>
> I've also tried various combinations:
>
> ssh  -t crawl_user@159.203.185.29  "'nohup screen -rD -S crawlSession &'"
> ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession &"
>
> The goal, to test if I can actually fire up/simulate the manual
> process that you get when you do
>
> ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession"
>
> Which displays the screen session, and also has the actual "screen
> -rD..." process in the procTBL..
>
> thanks...
>
> On Fri, Nov 18, 2016 at 9:15 AM, bruce  wrote:
> > trivial it is!!
> >
> > My inability to solve this in a few mins, says more about me, than the
> > difficulty of the prob!
> >
> > The following:
> > ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
> >
> > will attach to a detached named screen session.. the term pops up with
> > the attached screen from the SSH.. This is verified by having a sep
> > term, where I do a screen -ls and see that the screen is "Attached".
> >
> > However, the term, shows the screen/term/cmdline prompt. If I manually
> > enter "CRTL-A d" the process, detaches the screen and the term returns
> > to the calling env...
> >
> > My question!!
> >
> > How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
> >
> > When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> > $ printf '\001'
> > $ printf '\004'
> >
> > Which I saw somewhere was the process to generate the "Ctrl-a d"
> > sequence.. but this didn't work.
> >
> > I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
> >
> > Here's why I'm asking...
> >
> > I created a test script (php) to fire off the actual remote cmd to be
> > run in the screen session via SSH.. It doesn't work when it gets run..
> > The test script fires off the screen, with the attribute changed being
> > 'r' or 'x' based on the attach/detach of the screen..
> >
> > However, if I go into the target vm and then attach/detach the screen
> > (which should put the screen session back to the initial state), and I
> > then run the test app, The app runs correctly.. and the remote process
> > runs..
> >
> > So, I want to test how to simulate/perform the same process in a test script.
> >
> > Thanks..
> >
> > On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > > On 11/17/2016 09:47 AM, bruce wrote:
> > > > Hey Rick...
> > > >
> > > > More testing....
> > > >
> > > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > > def check it though.
> > > >
> > > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > > session was attached/detached, and implemented the remote app based on
> > > > that.. As I said a kludge ,but it works for now..
> > > >
> > > > As to the "real issue" of why I was getting weird behaviours..
> > > >
> > > > I had somehow managed to have an existing screen session with 'test'..
> > > > in my testing, I created a 2nd session with 'test', and then when I
> > > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > > run...
> > > >
> > > > I stuck a check to not create the session name, if it already exists..
> > > > now running again...
> > > >
> > > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > > check that out...
> > > >
> > > > If both parts look 'good'...
> > > >
> > > > This thing is getting close to being able to fire up to go fetch data
> > > > from the 300-400 colleges..
> > > >
> > > > I know.. relatively trivial when you look at it..
> > >
> > > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> > >     Build no mechanism simply if a way can be found to make it
> > >     complex and wonderful. This also justifies your existence and
> > >     paycheck.
> > >
> > > Phelps' corollary to that states:
> > >     If it was easy, everyone would do it.
> > >
> > > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > > aha!!
> > > > > >
> > > > > > ok.. more testing, more insight into whats going on...
> > > > > >
> > > > > > the basic setup
> > > > > >  client box (boxA) - running the screen session 'test'
> > > > > >
> > > > > > local box (boxB) - invokes the ssh/screen/remote app
> > > > > >
> > > > > > test I)
> > > > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > > > >   works if the test screen session on boxA is detached!!!
> > > > > >   --the screen/remote is created by screen -r 'test' ...
> > > > > >
> > > > > > however, if i attach the test screen session on boxA
> > > > > >   using screen -r 'test'
> > > > > > and then run the test app on boxB,
> > > > > >   --using ssh -- screen -r 'test' ...
> > > > > >   to run the remote within the named screen session...
> > > > > >
> > > > > > the process doesn't work.. .
> > > > > >   -now, if I change the test app on BoxB to use
> > > > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > > >
> > > > > > then this works, even though the 'test' screen session is already attached!!
> > > > > >
> > > > > > ok.. this more or less makes sense..
> > > > > >
> > > > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > > > >  session regardless of the session being attached/detached..
> > > > > >
> > > > > > I can't see any attribute for screen that allows that.. but I might
> > > > > > simply be missing something..
> > > > >
> > > > > Your description is very difficult to follow for me. Perhaps the
> > > > > formatting is mucked up.
> > > > >
> > > > > To run a process in the background WITHOUT attaching to the screen
> > > > > session, launch the process using
> > > > >     screen -d -m -S sessname 'script parm1 parm2'
> > > > >
> > > > > This will cause screen to create a session named "sessname" and launch
> > > > > the script WITHOUT creating an attached session. We use this all the
> > > > > time to launch long running processes at boot time that require a
> > > > > console.
> > > > >
> > > > > If you want to attach to the session thus launched, use
> > > > >     screen -r sessname
> > > > >
> > > > > Note that if you want to see the output of a screen session, you must
> > > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > > file.
> > > > >
> > > > > If you want to run in what is called "multi display" mode, then
> > > > >     screen -x -r sessname
> > > > >
> > > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > > or fourth) terminal to a session that already is attached to give you
> > > > > another terminal to communicate with it. You can think of it as a form
> > > > > of "screen sharing".
> > > > >
> > > > > I won't swear to it but I think if you use "-x" on a session that
> > > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > > session running).
> > > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> > >                                                                -
> > >    Is it progress if a cannibal uses a knife and fork?         -
> > >                              -- Stanislaw J. Lec               -
> > >
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]

[Rick Stevens]

On 11/18/2016 09:51 AM, bruce wrote:
> hmm...
>
> Think I resolved the issue of the ctrl-a d -- sequence, It appears
> screen -X allows for the use of tags, so the "detach" appears to be a
> substitute for the ctrl-A d sequence..
>
> However, I'm still flumoxed on how to run a background process on the remote vm.
>
> The following "should" work, but it doesn''t
>
> ssh  -t crawl_user@159.203.185.29  "sh -c 'nohup screen -rD -S crawlSession &'"
>
> I've also tried various combinations:
>
> ssh  -t crawl_user@159.203.185.29  "'nohup screen -rD -S crawlSession &'"
> ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession &"

Why do you insist on not using the "-d -m" options to launch a screen
session in the background? If you don't give it a command, it simply
starts an interactive shell session:

ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession"

(don't bother with the "-t" to ssh...you don't need a pseudo-TTY for
this). That would leave a detached screen session with a shell running
on the host 159.203.185.29. If you were to "ssh" to that machine and do
a "screen -ls", you'd see something like:

[root@159.203.185.29 ~]# screen -ls
    There is a screen on:
    	10424.crawlSession	(Detached)
    1 Socket in /var/run/screen/S-root.

You could "screen -r" to attach to that session, run whatever commands
you want, and detach again via "CTRL-A d", leaving the shell session
running. If you exit that shell while attached to it, then the session
ends.

If you did:

ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession top"

then the same screen session is started, but instead of a simple shell
it'd be running "top" in that session. If you "screen -r" to attach to
it, you can watch the top run. You can detach via "CTRL-A d" and top
would continue to run in the (newly re-detached) session.

If you quit top in that session (by typing "q" to quit top), you WON'T
be returned to an idle shell in the screen session. The screen session
itself ends because the top command finished (you told it to run top
and end when top is done) and you'll be returned to the point where you
issued the "screen -r".

Does that make it any clearer?
> The goal, to test if I can actually fire up/simulate the manual
> process that you get when you do
>
> ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession"
>
> Which displays the screen session, and also has the actual "screen
> -rD..." process in the procTBL..
>
> thanks...
>
> On Fri, Nov 18, 2016 at 9:15 AM, bruce  wrote:
> > trivial it is!!
> >
> > My inability to solve this in a few mins, says more about me, than the
> > difficulty of the prob!
> >
> > The following:
> > ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
> >
> > will attach to a detached named screen session.. the term pops up with
> > the attached screen from the SSH.. This is verified by having a sep
> > term, where I do a screen -ls and see that the screen is "Attached".
> >
> > However, the term, shows the screen/term/cmdline prompt. If I manually
> > enter "CRTL-A d" the process, detaches the screen and the term returns
> > to the calling env...
> >
> > My question!!
> >
> > How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
> >
> > When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> > $ printf '\001'
> > $ printf '\004'
> >
> > Which I saw somewhere was the process to generate the "Ctrl-a d"
> > sequence.. but this didn't work.
> >
> > I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
> >
> > Here's why I'm asking...
> >
> > I created a test script (php) to fire off the actual remote cmd to be
> > run in the screen session via SSH.. It doesn't work when it gets run..
> > The test script fires off the screen, with the attribute changed being
> > 'r' or 'x' based on the attach/detach of the screen..
> >
> > However, if I go into the target vm and then attach/detach the screen
> > (which should put the screen session back to the initial state), and I
> > then run the test app, The app runs correctly.. and the remote process
> > runs..
> >
> > So, I want to test how to simulate/perform the same process in a test script.
> >
> > Thanks..
> >
> > On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > > On 11/17/2016 09:47 AM, bruce wrote:
> > > > Hey Rick...
> > > >
> > > > More testing....
> > > >
> > > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > > def check it though.
> > > >
> > > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > > session was attached/detached, and implemented the remote app based on
> > > > that.. As I said a kludge ,but it works for now..
> > > >
> > > > As to the "real issue" of why I was getting weird behaviours..
> > > >
> > > > I had somehow managed to have an existing screen session with 'test'..
> > > > in my testing, I created a 2nd session with 'test', and then when I
> > > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > > run...
> > > >
> > > > I stuck a check to not create the session name, if it already exists..
> > > > now running again...
> > > >
> > > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > > check that out...
> > > >
> > > > If both parts look 'good'...
> > > >
> > > > This thing is getting close to being able to fire up to go fetch data
> > > > from the 300-400 colleges..
> > > >
> > > > I know.. relatively trivial when you look at it..
> > >
> > > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> > >     Build no mechanism simply if a way can be found to make it
> > >     complex and wonderful. This also justifies your existence and
> > >     paycheck.
> > >
> > > Phelps' corollary to that states:
> > >     If it was easy, everyone would do it.
> > >
> > > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > > aha!!
> > > > > >
> > > > > > ok.. more testing, more insight into whats going on...
> > > > > >
> > > > > > the basic setup
> > > > > >  client box (boxA) - running the screen session 'test'
> > > > > >
> > > > > > local box (boxB) - invokes the ssh/screen/remote app
> > > > > >
> > > > > > test I)
> > > > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > > > >   works if the test screen session on boxA is detached!!!
> > > > > >   --the screen/remote is created by screen -r 'test' ...
> > > > > >
> > > > > > however, if i attach the test screen session on boxA
> > > > > >   using screen -r 'test'
> > > > > > and then run the test app on boxB,
> > > > > >   --using ssh -- screen -r 'test' ...
> > > > > >   to run the remote within the named screen session...
> > > > > >
> > > > > > the process doesn't work.. .
> > > > > >   -now, if I change the test app on BoxB to use
> > > > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > > >
> > > > > > then this works, even though the 'test' screen session is already attached!!
> > > > > >
> > > > > > ok.. this more or less makes sense..
> > > > > >
> > > > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > > > >  session regardless of the session being attached/detached..
> > > > > >
> > > > > > I can't see any attribute for screen that allows that.. but I might
> > > > > > simply be missing something..
> > > > >
> > > > > Your description is very difficult to follow for me. Perhaps the
> > > > > formatting is mucked up.
> > > > >
> > > > > To run a process in the background WITHOUT attaching to the screen
> > > > > session, launch the process using
> > > > >     screen -d -m -S sessname 'script parm1 parm2'
> > > > >
> > > > > This will cause screen to create a session named "sessname" and launch
> > > > > the script WITHOUT creating an attached session. We use this all the
> > > > > time to launch long running processes at boot time that require a
> > > > > console.
> > > > >
> > > > > If you want to attach to the session thus launched, use
> > > > >     screen -r sessname
> > > > >
> > > > > Note that if you want to see the output of a screen session, you must
> > > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > > file.
> > > > >
> > > > > If you want to run in what is called "multi display" mode, then
> > > > >     screen -x -r sessname
> > > > >
> > > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > > or fourth) terminal to a session that already is attached to give you
> > > > > another terminal to communicate with it. You can think of it as a form
> > > > > of "screen sharing".
> > > > >
> > > > > I won't swear to it but I think if you use "-x" on a session that
> > > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > > session running).
> > > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> > >                                                                -
> > >    Is it progress if a cannibal uses a knife and fork?         -
> > >                              -- Stanislaw J. Lec               -
> > >
> > > 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...

Thanks for the input. Really appreciate it.

The issue I seem to have involves how to attach to a screen that's been created.

I start the base process, with the following.

ssh crawl_user@159.203.185.29 "screen -d -m -S 'crawlSession' "

which creates a detached session.

What you said about top is exactly how screen runs..

But what I wanted, was a screen session that is always "present",
where I could "run" remote cmds in the screen.

As far as I can tell, invoking a session as above will get you a
detached screen, that should be able to be attached to, so you can
then use the -X stuff attributes to push the remote cmd into the
screen.

Manually, this is trivial.

If I create a session as above, and then manually, attach/detach from
it (locally) I can then do something like

ssh  -t crawl_user@192.241.144.139  "screen -r -S crawlSession  -X
stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
ssh  -t crawl_user@192.241.144.139  "screen -x -S crawlSession  -X
stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "

and in the screen/session the output is there on the local vm, no prob...

However, if I attempt to handle the "detach"  portion via code in the
cod that does the SSH,  that's where the prob happens.

It really looks as if you can trivially do a "attach"
> > > ssh crawl_user@159.203.185.29 "screen -r -S 'crawlSession' "

or some variant of this..

but feeding the associated "Ctrl-A,d" sequence to detach is the issue.

In all honesty if one could do an attach, and then leave it alone.. no prob.

But I haven't found a way to place the SSH/screen cmd into the bg,
such that the remote vm shows the screen (attached) process in the
procTBL..

if on the other hand, you do a screen -r -S 'Foo' locally, this kicks
the attached session into gear, and you can see the screen process in
the procTBL...

Now, you can ask.. hey if you create a session, and then you
attach/detach, isnt that  pretty much the same as just creating it???
Why would that work, but not just the creation process for the
session!!! Well.. that's a good question that I ask myself!!

I even created a quick instance that has the initial screen session
created on bootup.. To see if there's a way to attach/detach via
bash/locally, to see if this solves the issue..

At this point.. I'm really curious now as to what the heck I'm missing.

I was also considering a dummy script that sleeps for 10 hrs, runs,
and repeats... this would be run when the session is created. and
basically procide the attached status for the session.. But that's a
kludge at best...

I think, if I could figure out how to locally attach/detach a screen
session via a script,
 the prob would be solved..

-------------------------
basic steps/flow::

Create the screen session
            ssh crawl_user@".$ip.' "screen -d -m -S '."'crawlSession' ".'"';

//creates a detached screen
//--should be able to now, just attach to the session, and feed in the
cmd to be run..
    --however never able to get this to run...

ssh  -t crawl_user@192.241.144.139  "screen -r -S crawlSession  -X
stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
ssh  -t crawl_user@192.241.144.139  "screen -x -S crawlSession  -X
stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "

//--the above with the '-r' should work!!
  the above was tested as well as tested using just the "-X" without the stuff..
  the \015 is for

On Fri, Nov 18, 2016 at 6:39 PM, Rick Stevens  wrote:
> On 11/18/2016 09:51 AM, bruce wrote:
> > hmm...
> >
> > Think I resolved the issue of the ctrl-a d -- sequence, It appears
> > screen -X allows for the use of tags, so the "detach" appears to be a
> > substitute for the ctrl-A d sequence..
> >
> > However, I'm still flumoxed on how to run a background process on the remote vm.
> >
> > The following "should" work, but it doesn''t
> >
> > ssh  -t crawl_user@159.203.185.29  "sh -c 'nohup screen -rD -S crawlSession &'"
> >
> > I've also tried various combinations:
> >
> > ssh  -t crawl_user@159.203.185.29  "'nohup screen -rD -S crawlSession &'"
> > ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession &"
>
> Why do you insist on not using the "-d -m" options to launch a screen
> session in the background? If you don't give it a command, it simply
> starts an interactive shell session:
>     ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession"
>
> (don't bother with the "-t" to ssh...you don't need a pseudo-TTY for
> this). That would leave a detached screen session with a shell running
> on the host 159.203.185.29. If you were to "ssh" to that machine and do
> a "screen -ls", you'd see something like:
>     [root@159.203.185.29 ~]# screen -ls
>     There is a screen on:
>             10424.crawlSession      (Detached)
>     1 Socket in /var/run/screen/S-root.
>
> You could "screen -r" to attach to that session, run whatever commands
> you want, and detach again via "CTRL-A d", leaving the shell session
> running. If you exit that shell while attached to it, then the session
> ends.
>
> If you did:
>     ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession top"
>
> then the same screen session is started, but instead of a simple shell
> it'd be running "top" in that session. If you "screen -r" to attach to
> it, you can watch the top run. You can detach via "CTRL-A d" and top
> would continue to run in the (newly re-detached) session.
>
> If you quit top in that session (by typing "q" to quit top), you WON'T
> be returned to an idle shell in the screen session. The screen session
> itself ends because the top command finished (you told it to run top
> and end when top is done) and you'll be returned to the point where you
> issued the "screen -r".
>
> Does that make it any clearer?
> > The goal, to test if I can actually fire up/simulate the manual
> > process that you get when you do
> >
> > ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession"
> >
> > Which displays the screen session, and also has the actual "screen
> > -rD..." process in the procTBL..
> >
> > thanks...
> >
> > On Fri, Nov 18, 2016 at 9:15 AM, bruce  wrote:
> > > trivial it is!!
> > >
> > > My inability to solve this in a few mins, says more about me, than the
> > > difficulty of the prob!
> > >
> > > The following:
> > > ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
> > >
> > > will attach to a detached named screen session.. the term pops up with
> > > the attached screen from the SSH.. This is verified by having a sep
> > > term, where I do a screen -ls and see that the screen is "Attached".
> > >
> > > However, the term, shows the screen/term/cmdline prompt. If I manually
> > > enter "CRTL-A d" the process, detaches the screen and the term returns
> > > to the calling env...
> > >
> > > My question!!
> > >
> > > How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
> > >
> > > When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> > > $ printf '\001'
> > > $ printf '\004'
> > >
> > > Which I saw somewhere was the process to generate the "Ctrl-a d"
> > > sequence.. but this didn't work.
> > >
> > > I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
> > >
> > > Here's why I'm asking...
> > >
> > > I created a test script (php) to fire off the actual remote cmd to be
> > > run in the screen session via SSH.. It doesn't work when it gets run..
> > > The test script fires off the screen, with the attribute changed being
> > > 'r' or 'x' based on the attach/detach of the screen..
> > >
> > > However, if I go into the target vm and then attach/detach the screen
> > > (which should put the screen session back to the initial state), and I
> > > then run the test app, The app runs correctly.. and the remote process
> > > runs..
> > >
> > > So, I want to test how to simulate/perform the same process in a test script.
> > >
> > > Thanks..
> > >
> > > On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > > > On 11/17/2016 09:47 AM, bruce wrote:
> > > > > Hey Rick...
> > > > >
> > > > > More testing....
> > > > >
> > > > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > > > def check it though.
> > > > >
> > > > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > > > session was attached/detached, and implemented the remote app based on
> > > > > that.. As I said a kludge ,but it works for now..
> > > > >
> > > > > As to the "real issue" of why I was getting weird behaviours..
> > > > >
> > > > > I had somehow managed to have an existing screen session with 'test'..
> > > > > in my testing, I created a 2nd session with 'test', and then when I
> > > > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > > > run...
> > > > >
> > > > > I stuck a check to not create the session name, if it already exists..
> > > > > now running again...
> > > > >
> > > > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > > > check that out...
> > > > >
> > > > > If both parts look 'good'...
> > > > >
> > > > > This thing is getting close to being able to fire up to go fetch data
> > > > > from the 300-400 colleges..
> > > > >
> > > > > I know.. relatively trivial when you look at it..
> > > >
> > > > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> > > >     Build no mechanism simply if a way can be found to make it
> > > >     complex and wonderful. This also justifies your existence and
> > > >     paycheck.
> > > >
> > > > Phelps' corollary to that states:
> > > >     If it was easy, everyone would do it.
> > > >
> > > > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > > > aha!!
> > > > > > >
> > > > > > > ok.. more testing, more insight into whats going on...
> > > > > > >
> > > > > > > the basic setup
> > > > > > >  client box (boxA) - running the screen session 'test'
> > > > > > >
> > > > > > >  local box (boxB) - invokes the ssh/screen/remote app
> > > > > > >
> > > > > > > test I)
> > > > > > > -running the test app on boxB that invokes the ssh/screen remote app
> > > > > > >   works if the test screen session on boxA is detached!!!
> > > > > > >   --the screen/remote is created by screen -r 'test' ...
> > > > > > >
> > > > > > > however, if i attach the test screen session on boxA
> > > > > > >   using screen -r 'test'
> > > > > > > and then run the test app on boxB,
> > > > > > >   --using ssh -- screen -r 'test' ...
> > > > > > >   to run the remote within the named screen session...
> > > > > > >
> > > > > > >   the process doesn't work.. .
> > > > > > >   -now, if I change the test app on BoxB to use
> > > > > > >   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > > > >
> > > > > > > then this works, even though the 'test' screen session is already attached!!
> > > > > > >
> > > > > > > ok.. this more or less makes sense..
> > > > > > >
> > > > > > > So, it appears that I need some way of attaching to the named 'test' screen
> > > > > > >  session regardless of the session being attached/detached..
> > > > > > >
> > > > > > > I can't see any attribute for screen that allows that.. but I might
> > > > > > > simply be missing something..
> > > > > >
> > > > > > Your description is very difficult to follow for me. Perhaps the
> > > > > > formatting is mucked up.
> > > > > >
> > > > > > To run a process in the background WITHOUT attaching to the screen
> > > > > > session, launch the process using
> > > > > >     screen -d -m -S sessname 'script parm1 parm2'
> > > > > >
> > > > > > This will cause screen to create a session named "sessname" and launch
> > > > > > the script WITHOUT creating an attached session. We use this all the
> > > > > > time to launch long running processes at boot time that require a
> > > > > > console.
> > > > > >
> > > > > > If you want to attach to the session thus launched, use
> > > > > >     screen -r sessname
> > > > > >
> > > > > > Note that if you want to see the output of a screen session, you must
> > > > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > > > file.
> > > > > >
> > > > > > If you want to run in what is called "multi display" mode, then
> > > > > >     screen -x -r sessname
> > > > > >
> > > > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > > > or fourth) terminal to a session that already is attached to give you
> > > > > > another terminal to communicate with it. You can think of it as a form
> > > > > > of "screen sharing".
> > > > > >
> > > > > > I won't swear to it but I think if you use "-x" on a session that
> > > > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > > > session running).
> > > > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > > > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> > > >                                                                -
> > > >    Is it progress if a cannibal uses a knife and fork?         -
> > > >                              -- Stanislaw J. Lec               -
> > > >
> > > > 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 -
>                                                                -
> Overweight:  When you step on your dog's tail...and it dies.    -
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[bruce]

AHAA!!!!!!!

High fives!!!!!  fist bumps!!!!!

Rick (and others...)

After wayyyyyyy too long my ssh screen process to run a remote app via
screen works..

Really quite simple!

//--this crafts the initial named screen session.. no app detached..
ssh   crawl_user@67.205.145.36  "screen -dmS 'crawlSession '

//--this then attaches to the named/detached session, and the window '-p 0'
//-- and runs the app, with a "cr"
ssh   crawl_user@192.241.144.139  "screen -r -p 0 -S 'crawlSession'
-X stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "

The prob that had been happening, is that I completely missed testing
against the window attribute. I had assumed it wasn't needed!!

Funny thing, i saw the window attribute in the 1st 5-10 mins of
looking at the screen cmd man page..and just glossed over it!

Lord!! smh...

Thanks guys... (and maybe this will help someone out there!)

On Fri, Nov 18, 2016 at 8:01 PM, bruce  wrote:
> Hey Rick...
>
> Thanks for the input. Really appreciate it.
>
> The issue I seem to have involves how to attach to a screen that's been created.
>
> I start the base process, with the following.
>      ssh crawl_user@159.203.185.29 "screen -d -m -S 'crawlSession' "
>
> which creates a detached session.
>
> What you said about top is exactly how screen runs..
>
> But what I wanted, was a screen session that is always "present",
> where I could "run" remote cmds in the screen.
>
> As far as I can tell, invoking a session as above will get you a
> detached screen, that should be able to be attached to, so you can
> then use the -X stuff attributes to push the remote cmd into the
> screen.
>
> Manually, this is trivial.
>
> If I create a session as above, and then manually, attach/detach from
> it (locally) I can then do something like
>
> ssh  -t crawl_user@192.241.144.139  "screen -r -S crawlSession  -X
> stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
> ssh  -t crawl_user@192.241.144.139  "screen -x -S crawlSession  -X
> stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
>
> and in the screen/session the output is there on the local vm, no prob...
>
> However, if I attempt to handle the "detach"  portion via code in the
> cod that does the SSH,  that's where the prob happens.
>
> It really looks as if you can trivially do a "attach"
> > > > ssh crawl_user@159.203.185.29 "screen -r -S 'crawlSession' "
>
> or some variant of this..
>
> but feeding the associated "Ctrl-A,d" sequence to detach is the issue.
>
> In all honesty if one could do an attach, and then leave it alone.. no prob.
>
> But I haven't found a way to place the SSH/screen cmd into the bg,
> such that the remote vm shows the screen (attached) process in the
> procTBL..
>
> if on the other hand, you do a screen -r -S 'Foo' locally, this kicks
> the attached session into gear, and you can see the screen process in
> the procTBL...
>
> Now, you can ask.. hey if you create a session, and then you
> attach/detach, isnt that  pretty much the same as just creating it???
> Why would that work, but not just the creation process for the
> session!!! Well.. that's a good question that I ask myself!!
>
> I even created a quick instance that has the initial screen session
> created on bootup.. To see if there's a way to attach/detach via
> bash/locally, to see if this solves the issue..
>
> At this point.. I'm really curious now as to what the heck I'm missing.
>
> I was also considering a dummy script that sleeps for 10 hrs, runs,
> and repeats... this would be run when the session is created. and
> basically procide the attached status for the session.. But that's a
> kludge at best...
>
> I think, if I could figure out how to locally attach/detach a screen
> session via a script,
>  the prob would be solved..
>
> basic steps/flow::
>
> Create the screen session
>             ssh crawl_user@".$ip.' "screen -d -m -S '."'crawlSession' ".'"';
>
> //creates a detached screen
> //--should be able to now, just attach to the session, and feed in the
> cmd to be run..
>     --however never able to get this to run...
>
> ssh  -t crawl_user@192.241.144.139  "screen -r -S crawlSession  -X
> stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
> ssh  -t crawl_user@192.241.144.139  "screen -x -S crawlSession  -X
> stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "
>
> //--the above with the '-r' should work!!
>   the above was tested as well as tested using just the "-X" without the stuff..
>   the \015 is for
>
> On Fri, Nov 18, 2016 at 6:39 PM, Rick Stevens  wrote:
> > On 11/18/2016 09:51 AM, bruce wrote:
> > > hmm...
> > >
> > > Think I resolved the issue of the ctrl-a d -- sequence, It appears
> > > screen -X allows for the use of tags, so the "detach" appears to be a
> > > substitute for the ctrl-A d sequence..
> > >
> > > However, I'm still flumoxed on how to run a background process on the remote vm.
> > >
> > > The following "should" work, but it doesn''t
> > >
> > > ssh  -t crawl_user@159.203.185.29  "sh -c 'nohup screen -rD -S crawlSession &'"
> > >
> > > I've also tried various combinations:
> > >
> > > ssh  -t crawl_user@159.203.185.29  "'nohup screen -rD -S crawlSession &'"
> > > ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession &"
> >
> > Why do you insist on not using the "-d -m" options to launch a screen
> > session in the background? If you don't give it a command, it simply
> > starts an interactive shell session:
> >     ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession"
> >
> > (don't bother with the "-t" to ssh...you don't need a pseudo-TTY for
> > this). That would leave a detached screen session with a shell running
> > on the host 159.203.185.29. If you were to "ssh" to that machine and do
> > a "screen -ls", you'd see something like:
> >     [root@159.203.185.29 ~]# screen -ls
> >     There is a screen on:
> >             10424.crawlSession      (Detached)
> >     1 Socket in /var/run/screen/S-root.
> >
> > You could "screen -r" to attach to that session, run whatever commands
> > you want, and detach again via "CTRL-A d", leaving the shell session
> > running. If you exit that shell while attached to it, then the session
> > ends.
> >
> > If you did:
> >     ssh crawl_user@159.203.185.29 "screen -d -m -S crawlSession top"
> >
> > then the same screen session is started, but instead of a simple shell
> > it'd be running "top" in that session. If you "screen -r" to attach to
> > it, you can watch the top run. You can detach via "CTRL-A d" and top
> > would continue to run in the (newly re-detached) session.
> >
> > If you quit top in that session (by typing "q" to quit top), you WON'T
> > be returned to an idle shell in the screen session. The screen session
> > itself ends because the top command finished (you told it to run top
> > and end when top is done) and you'll be returned to the point where you
> > issued the "screen -r".
> >
> > Does that make it any clearer?
> > > The goal, to test if I can actually fire up/simulate the manual
> > > process that you get when you do
> > >
> > > ssh  -t crawl_user@159.203.185.29  "screen -rD -S crawlSession"
> > >
> > > Which displays the screen session, and also has the actual "screen
> > > -rD..." process in the procTBL..
> > >
> > > thanks...
> > >
> > > On Fri, Nov 18, 2016 at 9:15 AM, bruce  wrote:
> > > > trivial it is!!
> > > >
> > > > My inability to solve this in a few mins, says more about me, than the
> > > > difficulty of the prob!
> > > >
> > > > The following:
> > > > ssh  -t crawl_user@67.205.135.251   "screen  -RDS crawlSession
> > > >
> > > > will attach to a detached named screen session.. the term pops up with
> > > > the attached screen from the SSH.. This is verified by having a sep
> > > > term, where I do a screen -ls and see that the screen is "Attached".
> > > >
> > > > However, the term, shows the screen/term/cmdline prompt. If I manually
> > > > enter "CRTL-A d" the process, detaches the screen and the term returns
> > > > to the calling env...
> > > >
> > > > My question!!
> > > >
> > > > How the heck can one replicate the "Ctrl-A d" sequence in either shell or py?
> > > >
> > > > When in the screen session at the term/cursor/cmdline prompt I tried to enter:
> > > > $ printf '\001'
> > > > $ printf '\004'
> > > >
> > > > Which I saw somewhere was the process to generate the "Ctrl-a d"
> > > > sequence.. but this didn't work.
> > > >
> > > > I've also seen somewhere, where the ^Ad was the sequence again ,no luck..
> > > >
> > > > Here's why I'm asking...
> > > >
> > > > I created a test script (php) to fire off the actual remote cmd to be
> > > > run in the screen session via SSH.. It doesn't work when it gets run..
> > > > The test script fires off the screen, with the attribute changed being
> > > > 'r' or 'x' based on the attach/detach of the screen..
> > > >
> > > > However, if I go into the target vm and then attach/detach the screen
> > > > (which should put the screen session back to the initial state), and I
> > > > then run the test app, The app runs correctly.. and the remote process
> > > > runs..
> > > >
> > > > So, I want to test how to simulate/perform the same process in a test script.
> > > >
> > > > Thanks..
> > > >
> > > > On Thu, Nov 17, 2016 at 1:05 PM, Rick Stevens  wrote:
> > > > > On 11/17/2016 09:47 AM, bruce wrote:
> > > > > > Hey Rick...
> > > > > >
> > > > > > More testing....
> > > > > >
> > > > > > Not sure if you can use the "-x -r" attributes at the same time.. I'll
> > > > > > def check it though.
> > > > > >
> > > > > > As a kludge/workaround.. I did a quick screen -ls to check if the
> > > > > > session was attached/detached, and implemented the remote app based on
> > > > > > that.. As I said a kludge ,but it works for now..
> > > > > >
> > > > > > As to the "real issue" of why I was getting weird behaviours..
> > > > > >
> > > > > > I had somehow managed to have an existing screen session with 'test'..
> > > > > > in my testing, I created a 2nd session with 'test', and then when I
> > > > > > was doing the remote app -- using the name 'test'.. it blew up/didn't
> > > > > > run...
> > > > > >
> > > > > > I stuck a check to not create the session name, if it already exists..
> > > > > > now running again...
> > > > > >
> > > > > > Once I get all of this working.. I'll jump to the clusterSSH.. to
> > > > > > check that out...
> > > > > >
> > > > > > If both parts look 'good'...
> > > > > >
> > > > > > This thing is getting close to being able to fire up to go fetch data
> > > > > > from the 300-400 colleges..
> > > > > >
> > > > > > I know.. relatively trivial when you look at it..
> > > > >
> > > > > NEVER say it's "trivial". Engineering criterium #7 clearly states:
> > > > >     Build no mechanism simply if a way can be found to make it
> > > > >     complex and wonderful. This also justifies your existence and
> > > > >     paycheck.
> > > > >
> > > > > Phelps' corollary to that states:
> > > > >     If it was easy, everyone would do it.
> > > > >
> > > > > > On Thu, Nov 17, 2016 at 12:36 PM, Rick Stevens  wrote:
> > > > > > > On 11/17/2016 07:14 AM, bruce wrote:
> > > > > > >> aha!!
> > > > > > >>
> > > > > > >> ok.. more testing, more insight into whats going on...
> > > > > > >>
> > > > > > >> the basic setup
> > > > > > >>  client box (boxA) - running the screen session 'test'
> > > > > > >>
> > > > > > >>  local box (boxB) - invokes the ssh/screen/remote app
> > > > > > >>
> > > > > > >> test I)
> > > > > > >> -running the test app on boxB that invokes the ssh/screen remote app
> > > > > > >>   works if the test screen session on boxA is detached!!!
> > > > > > >>   --the screen/remote is created by screen -r 'test' ...
> > > > > > >>
> > > > > > >> however, if i attach the test screen session on boxA
> > > > > > >>   using screen -r 'test'
> > > > > > >> and then run the test app on boxB,
> > > > > > >>   --using ssh -- screen -r 'test' ...
> > > > > > >>   to run the remote within the named screen session...
> > > > > > >>
> > > > > > >>   the process doesn't work.. .
> > > > > > >>   -now, if I change the test app on BoxB to use
> > > > > > >>   --using ssh -- screen -x 'test' ...    <<<<<<
> > > > > > >>
> > > > > > >> then this works, even though the 'test' screen session is already attached!!
> > > > > > >>
> > > > > > >> ok.. this more or less makes sense..
> > > > > > >>
> > > > > > >> So, it appears that I need some way of attaching to the named 'test' screen
> > > > > > >>  session regardless of the session being attached/detached..
> > > > > > >>
> > > > > > >> I can't see any attribute for screen that allows that.. but I might
> > > > > > >> simply be missing something..
> > > > > > >
> > > > > > > Your description is very difficult to follow for me. Perhaps the
> > > > > > > formatting is mucked up.
> > > > > > >
> > > > > > > To run a process in the background WITHOUT attaching to the screen
> > > > > > > session, launch the process using
> > > > > > >
> > > > > > >         screen -d -m -S sessname 'script parm1 parm2'
> > > > > > >
> > > > > > > This will cause screen to create a session named "sessname" and launch
> > > > > > > the script WITHOUT creating an attached session. We use this all the
> > > > > > > time to launch long running processes at boot time that require a
> > > > > > > console.
> > > > > > >
> > > > > > > If you want to attach to the session thus launched, use
> > > > > > >
> > > > > > >         screen -r sessname
> > > > > > >
> > > > > > > Note that if you want to see the output of a screen session, you must
> > > > > > > attach to it OR you must have its output logged via the "-L" option (or
> > > > > > > by using "CTRL-A H" in the session) and you can then "tail -f" the log
> > > > > > > file.
> > > > > > >
> > > > > > > If you want to run in what is called "multi display" mode, then
> > > > > > >
> > > > > > >         screen -x -r sessname
> > > > > > >
> > > > > > > should do it. The "-x" option allows you to attach a second (or third,
> > > > > > > or fourth) terminal to a session that already is attached to give you
> > > > > > > another terminal to communicate with it. You can think of it as a form
> > > > > > > of "screen sharing".
> > > > > > >
> > > > > > > I won't swear to it but I think if you use "-x" on a session that
> > > > > > > DOESN'T already have an attached terminal, then the "-x" is ignored and
> > > > > > > you attach normally (requiring the "CTRL-A d" to detach and leave the
> > > > > > > session running).
> > > > > Rick Stevens, Systems Engineer, AllDigital    [e-mail] -
> > > > > AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
> > > > >                                                                -
> > > > >    Is it progress if a cannibal uses a knife and fork?         -
> > > > >                              -- Stanislaw J. Lec               -
> > > > >
> > > > > 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 -
> >                                                                -
> > Overweight:  When you step on your dog's tail...and it dies.    -
> >
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Cameron Simpson]

On 19Nov2016 17:16, bruce  wrote:
> After wayyyyyyy too long my ssh screen process to run a remote app via
> screen works.. [...]
>
> //--this crafts the initial named screen session.. no app detached..
> ssh   crawl_user@67.205.145.36  "screen -dmS 'crawlSession '
>
> //--this then attaches to the named/detached session, and the window '-p 0'
> //-- and runs the app, with a "cr"
> ssh   crawl_user@192.241.144.139  "screen -r -p 0 -S 'crawlSession'
> -X stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015')  "

I'm glad you have your process sorted. Now to refine things a little!

You're passing (apparently) arbitrary strings to your remote ssh command, and 
slapping single quotes around these strings to keep them correct for the shell 
at the far end. If you know your strings will not themselves _ever_ have single 
quotes in them this will work, but why impose this (dangerously unwritten) 
requirement on your setup?

When I run an arbitrary remote command via ssh I invoke it via this wrapper:

https://bitbucket.org/cameron_simpson/css/src/tip/bin/sshx

which uses shqstr to quote the command line correctly. So your above commands, 
run this way, would look like:

session=crawlSession  # or whatever
  cr=$(echo -ne '\015')

sshx crawl_user@67.205.145.36 screen -dmS "$session"

sshx crawl_user@192.241.144.139 screen -r -p 0 -S "$session" -X stuff "/crawl_tmp/screen_test.php$cr"

so that you only need to get the local quoting correct. sshx needs shqstr, 
which is a python programme. There's a pure-shell version here:

https://bitbucket.org/cameron_simpson/css/src/tip/bin/shqstr-sh

Cheers,
Cameron Simpson