Re: [Fab-user] trivial put test case fails?

[Niklas Lindström]

Hi!

Christian got it! I moved the joins so it ends up like::

    # Close channel when done
    status = chan.recv_exit_status()
    chan.close()

    # Wait for threads to exit before returning (otherwise we will occasionally
    # end up returning before the threads have fully wrapped up)
    out_th.join()
    err_th.join()

    return ("".join(capture).strip(), status == 0)

And it worked. It hasn't stalled during my runs. (And seems like a
logical order of things.)


About the questions:

* tomcat6 stop and start both produce brief output:

    [rinfo-service] sudo: /etc/init.d/tomcat6 stop
    [rinfo-service] out:  * Stopping Tomcat servlet engine tomcat6
    [rinfo-service] out:    ...done.
    [rinfo-service] sudo: /etc/init.d/tomcat6 start
    [rinfo-service] out:  * Starting Tomcat servlet engine tomcat6
    [rinfo-service] out:    ...done.

-- as seen they don't spawn a process and exit but monitor the
operation synchronuously and exists when completed.

* The fabric process just hangs there without churning the CPU.

* Most stuff (mv, rm, untar etc.) worked just fine. So did doing a
restart (using stop+start) with apache2ctl (and the
"etc/init.d/apache2" version). Maybe it was about the length of the
operation (restarting tomcat takes a couple of seconds)?..

* Changing `chan.recv(65535)` changed nothing (tried both this alone,
and along with recv_stderr).


Anyway, moving the joins after `chan.close()` seems to have done it,
so I'm happy. :)

Best regards,
Niklas



On Sat, Feb 21, 2009 at 7:39 PM, Christian Vest Hansen
<address@hidden> wrote:
> On Sat, Feb 21, 2009 at 4:49 PM, Niklas Lindström <address@hidden> wrote:
>> Excellent! Put works for me now both for target-as-file and target-as-dir.
>>
>> However, the next step of my deploy freezes. It's just a tomcat
>> "two-step" restart done with:
>>
>>    def restart():
>>        sudo("/etc/init.d/tomcat6 stop", fail='warn')
>>        sudo("/etc/init.d/tomcat6 start")
>>
>> Actually stopping works, but startup hangs and the fabric process must
>> be killed (the actual startup on the server goes well). Commenting out
>> the newly added thread-joins in `sudo` (line 527, 528) works:
>>
>>    #out_th.join()
>>    #err_th.join()
>>
>> (I tried only join:ing `out_th`, and it worked sometimes, froze others.)
>>
>> I saw you discuss this earlier.. Is there anything I could experiment
>> with apart from just not using join? I suspect it's easily
>> reproducible, but I may be wrong. I run fabric trunk on Python 2.5, OS
>> X 10.5. Deployment is done to an Ubuntu 8.10 in VMWare (currently on
>> the same machine).
>
> Does the "tomcat6 start" produce any output? Can I assume that it
> completes almost immediately (doing the actual booting in another
> process)? Is the fabric process, when hung, using a lot of CPU or none
> at all?
>
> A thing you might try; instead of commenting the joins out, try moving
> them bellow the "status = chan.recv_exit_status()" line, and see if
> that changes the behavior in some way (I'm thinking lock-ordering with
> this experiment).
>
> Another thing: the outputter threads does stuff like
> "chan.recv(65535)" - try changing that value to something small, like
> 32. Although, I hope this doesn't change anything.
>
>>
>> Best regards,
>> Niklas
>>
>>
>> On Fri, Feb 20, 2009 at 6:53 AM, Christian Vest Hansen
>> <address@hidden> wrote:
>>> I pushed a fix to the repos. Tire-kicking encouraged.
>>>
>>> On Wed, Feb 18, 2009 at 10:15 PM, Niklas Lindström <address@hidden> wrote:
>>>> Hi!
>>>>
>>>> I just ran into this myself. No time to write a patch (afraid my
>>>> git-repo is a bit of a mess), but the issue is on line 389:
>>>>
>>>>    mode = ftp.lstat(remotepath).st_mode
>>>>
>>>> This fails if the remotepath doesn't exist. It *will* work if you use
>>>> the new *great* feature of put: you can supply a directory as the
>>>> second argument instead (which as seen breaks the old functionality..
>>>> ;]).
>>>>
>>>> A *crude* fix would be:
>>>>
>>>>    try:
>>>>        mode = ftp.lstat(remotepath).st_mode
>>>>    except:
>>>>        mode = None
>>>>
>>>> While I'm at it, it seems the glob feature (line 393+) can't work
>>>> either. On line 391, remotepath is turned from a directory to a file
>>>> path by taking the basename of the localpath. Which thus cannot be a
>>>> glob pattern? ;)
>>>>
>>>>
>>>> (Anyway, it was very nice to see a new release with the new stuff in
>>>> place! Congrats.)
>>>>
>>>> [Just saw Timothee found that using a directory works. So this is a
>>>> bugreport then.. ;)]
>>>>
>>>> Best regards,
>>>> Niklas
>>>>
>>>>
>>>>
>>>> On Wed, Feb 18, 2009 at 10:03 PM, Timothee Besset <address@hidden> wrote:
>>>>> I am trying to run the following test case:
>>>>>
>>>>> def test_put():
>>>>>    "Test a file put."
>>>>>    put( '/home/timo/bar', '/root/bar' )
>>>>>
>>>>> /home/timo/bar exists on my local system, I am logging in as root into
>>>>> the remote host just fine, but the put fails:
>>>>>
>>>>> $ fab test_put
>>>>> Fabric v. 0.1.0.
>>>>> Running test_put...
>>>>> Logging into the following hosts as root:
>>>>>    qls16
>>>>> Error: The put operation failed on qls16:
>>>>>    [Errno 2] No such file
>>>>>
>>>>> Does this functionality expect specific programs installed on the remote
>>>>> end maybe?
>>>>>
>>>>> TTimo
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Fab-user mailing list
>>>>> address@hidden
>>>>> http://lists.nongnu.org/mailman/listinfo/fab-user
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Fab-user mailing list
>>>> address@hidden
>>>> http://lists.nongnu.org/mailman/listinfo/fab-user
>>>>
>>>
>>>
>>>
>>> --
>>> Venlig hilsen / Kind regards,
>>> Christian Vest Hansen.
>>>
>>
>
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>