Re: ssh/screen question - thread

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

 



Hey Rick...

Morning dude! Thanks for the reply.

I've tried a bunch of different combinations, including the one you
posted.. What seems to be happening, is that I can get it to run. The
tmp file is generated with the data but the session doesn't
immeadiately detach. It only detaches after the process completes!!

In my case, I'm looking at having 100s of digitalocean droplets
running long running processes as part of the crawler. so I need to
fire off the crawling process, on the remote droplet via SSH get it
running in the named session, and then detach, with control going back
to the calling term/process, thus minimizing the number of ongoing SSH
connects...

I've tried
ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname"   -X "`sleep 100 `"  '
ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -d   -X
"`sleep 100 `"  '

ssh  -t crawl_user@192.81.214.49 'screen  -S "testname"   -X "`sleep 100 `"  '
ssh  -t crawl_user@192.81.214.49 'screen  -S "testname" -d   -X
"`sleep 100 `"  '

and a bunch of other combinations.. also tried without the "-t" ssh attribute..

I used the sleep to see if the process was actually waiting for the
process to complete before it detached.. the "ls..... " generated the
data to show the cmd was actually running.. but it wasn't a good way
to validate the session waiting for the completion before detaching.
Changing the sleep time, verified the behaviour.

I'm missing something.. and I know it's subtle.. but I can't see it..


On Mon, Nov 14, 2016 at 1:21 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx> wrote:
> On 11/14/2016 03:01 AM, bruce wrote:
>> Hi Jakub
>>
>> So you're saying
>>
>>>>>   ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`ls -al /crawl_tmp/* > aa.tmp`"  '
>> is not the correct approach to running a remote cmd in a screen
>> session, and that the cmd wrapped in the backticks is run on the local
>> machine, not the remote machine???
>>
>> changing the cmd, using the "-t" or the "-f" doesn't work either.
>> - also tried changing the quotes wrapping the remote cmd from double
>> to single quotes. as I understand it, the expansion of the cmd within
>> the quotes, changes depending on the single or double quote used.
>>
>> ssh  -t crawl_user@192.81.214.49 'screen -r "testname" -X "ls -al
>> /crawl_tmp/* > aa.tmp"  '
>> ssh  -t crawl_user@192.81.214.49 "screen -r "testname" -X 'ls -al
>> /crawl_tmp/* > aa.tmp'  "
>>
>>
>> So if you (or anyone else) has actual test cmds/funcs that I can
>> implement post, and I'll gladly test.
>>
>> But for now, can't seem to find the subtle error..
>
> I think you have to specify the screen session name by prefixing it
> with "-S" (the documentation is murky on this one--the "-r" should be
> enough). Try:
>
>         ssh  -t crawl_user@192.81.214.49 'screen -r -S "testname" -X "ls -al
> /crawl_tmp/* > aa.tmp"'
>
>> On Mon, Nov 14, 2016 at 3:05 AM, Jakub Jelen <jjelen@xxxxxxxxxx> wrote:
>>> On 11/14/2016 02:17 AM, bruce wrote:
>>>>
>>>> I think I'm getting closer to an actual soln...
>>>>
>>>>
>>>> ** Notice the backticks around the remote cmd to be run
>>>>   -without the ticks, the cmd doesn't appear to work
>>>>
>>>>
>>>> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup ls -al
>>>> /crawl_tmp/* > aa.tmp`"  '
>>>> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
>>>> '
>>>> ssh  crawl_user@192.81.214.49 'screen -r "testname" -X "`nohup sleep 10`"
>>>> & '
>>>>
>>>> If the backticks are required, ok the final part of the solution is to
>>>> make the whole thing run the cmd in the screen session, but return
>>>> back to the calling term, once the screen session/cmd starts.
>>>
>>>
>>> The backticks makes your command run in your local sub-shell, not the remote
>>> one.
>>>
>>> Also if you want interactive session, you need to use -t switch to the ssh
>>> command.
>>>
>>>
>>>> In other words I want the long running/remote process to start running
>>>> in the screen session and return the control to the calling term
>>>> without waiting for the completion of the process.
>>>>
>>>> With the basic tests using the sleep func.. it appears that my current
>>>> attempts aren't quite there yet.
>>>>
>>>> I don't want to put the remote/running cmd in the background, as that
>>>> would disable the ability to see/view the display output of the
>>>> process.
>>>>
>>>> Tried to put the screen process in the background.. no luck..
>>>>
>>>> Thoughts/comments???
>>>>
>>>> THanks
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Nov 13, 2016 at 1:00 PM, Patrick O'Callaghan
>>>> <pocallaghan@xxxxxxxxx> wrote:
>>>>>
>>>>> On Sun, 2016-11-13 at 10:09 -0500, bruce wrote:
>>>>>>
>>>>>>   The goal, to be able to reattach to a remote screen session, and to
>>>>>> run a cmd in the remote screen session, and have the cmd return to the
>>>>>> calling term
>>>>>
>>>>> Maybe take a look at expect (dnf info expect).
>>>>>
>>>>> poc
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> --
>>> Jakub Jelen
>>> Software Engineer
>>> Security Technologies
>>> Red Hat
>>>
>>> _______________________________________________
>>> 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 -
> -                                                                    -
> -    First Law of Work:                                              -
> -    If you can't get it done in the first 24 hours, work nights.    -
> ----------------------------------------------------------------------
> _______________________________________________
> 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