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
