AHAA!!!!!!! High fives!!!!! fist bumps!!!!! Rick (and others...) After wayyyyyyy too long my ssh screen process to run a remote app via screen works.. Really quite simple! //--this crafts the initial named screen session.. no app detached.. ssh crawl_user@67.205.145.36 "screen -dmS 'crawlSession ' //--this then attaches to the named/detached session, and the window '-p 0' //-- and runs the app, with a "cr" ssh crawl_user@192.241.144.139 "screen -r -p 0 -S 'crawlSession' -X stuff '/crawl_tmp/screen_test.php'$(echo -ne '\015') " The prob that had been happening, is that I completely missed testing against the window attribute. I had assumed it wasn't needed!! Funny thing, i saw the window attribute in the 1st 5-10 mins of looking at the screen cmd man page..and just glossed over it! Lord!! smh... Thanks guys... (and maybe this will help someone out there!) On Fri, Nov 18, 2016 at 8:01 PM, bruce <badouglas@xxxxxxxxx> wrote: > 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
