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 <badouglas@xxxxxxxxx> 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 <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
