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 <ricks@xxxxxxxxxxxxxx> 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 <badouglas@xxxxxxxxx> 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 <ricks@xxxxxxxxxxxxxx> 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 <ricks@xxxxxxxxxxxxxx> 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 ricks@xxxxxxxxxxxxxx -
>>>> - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
>>>> - -
>>>> - Is it progress if a cannibal uses a knife and fork? -
>>>> - -- Stanislaw J. Lec -
>>>> ----------------------------------------------------------------------
>>>> _______________________________________________
>>>> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
>>>> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> _______________________________________________
>> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>>
>
>
> --
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx -
> - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
> - -
> - Overweight: When you step on your dog's tail...and it dies. -
> ----------------------------------------------------------------------
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
