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
