Re: ssh/screen -- cmdline vs php

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



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 -
> -                                                                    -
> -          Consciousness: that annoying time between naps.           -
> ----------------------------------------------------------------------
> _______________________________________________
> 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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux