fab-user
[Top][All Lists]
Advanced

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

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


From: Jeff Forcier
Subject: Re: [Fab-user] trivial put test case fails?
Date: Sat, 21 Feb 2009 11:04:08 -0500

On Sat, Feb 21, 2009 at 10:49 AM, Niklas Lindström <address@hidden> wrote:

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

Question time:
- How does the tomcat 'start' option work when you invoke it on the
server directly? Does it exit cleanly or stick around for any reason?
- Are you having the same problems with any other commands you run remotely?
- Any way you can try invoking other commands which do the same thing
(since init.d scripts are sometimes just simple wrappers around e.g.
apachectl, not sure if tomcat has an equivalent binary)?


The stdout/stderr printer threads *should* stop once the SSH channel
signals that the remote end hung up, which should only happen when the
command executed is finished. So this tells me that for some reason
one or another of those signals aren't firing or being detected
correctly.

Threads (especially combined with stuff like network IO) are notorious
for having oddball problems, so this could be some edge case I haven't
run into yet. Sounds like another good reason to try and move away
from threads and towards asynchronous programming, if/when we can.
(That's next on my plate after the current, ambitious magic-removal
rewrite.)

Anyway, a temporary workaround could be to add another option to
run/sudo which is sort of an emergency shutoff of those outputter
threads. Result would be that the command would still execute
remotely, and you'd not get any output of any kind, printed or
returned -- but in return the threading behavior would be disabled for
that call, hopefully eliminating whatever is going on.


Let me know if you think that's necessary (but please poke around
first, per my questions!) and I can whip one up in my Github master
branch (which right now is up to date wrt the released 0.1.0).

-Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]