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 <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
