fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] tricky parallel execution


From: Dmitry Makovey
Subject: Re: [Fab-user] tricky parallel execution
Date: Mon, 10 Sep 2012 13:36:34 -0600
User-agent: KMail/4.8.5 (Linux/3.4.9-2.fc16.x86_64; KDE/4.8.5; x86_64; ; )

On September 10, 2012 12:03:45 Jeff Forcier wrote:
> On Mon, Sep 10, 2012 at 7:41 AM, Dmitry Makovey <address@hidden> 
wrote:
> > in case of postmaster - that is probably what I'll end up doing. However
> > before commiting to that I decided to play with os.fork():
> > 
> > <snip>
> > 
> > which seems to work but something tells me this approach may bite me in
> > the
> > end if Fabric keeps track of connections by "reference counts" and does
> > cleanup on SIGTERM - i.e. I'm destroying child and inadvertently
> > terminating connection with the server
> > 
> > So the question is: is above code really working or should I stay away
> > from
> > doing forks within tasks?
> 
> Re: handling kills/disconnects, Fabric keeps a module level dict
> holding the SSH connections and closes them at process exit
> (normally/imperatively, not via signal trapping).
> 
> So theoretically fork() will copy those objects for the child (if I
> remember how it works correctly) but the sockets they represent would
> be the same objects as the OS level -- so you'd get odd behavior or
> "Socket closed" errors if the child closed a connection the parent was
> using. (We got this in the existing parallel code until we cleared out
> that connection dict at the top of the child processes so they'd make
> their own, new sockets.)
> 
> That shouldn't matter a lot though, because run("command &") will
> actually sit there and block forever (see
> http://docs.fabfile.org/en/1.4.3/faq.html#why-can-t-i-run-programs-in-the-ba
> ckground-with-it-makes-fabric-hang), so your sleep & kill calls should never
> actually get executed. Not 100% sure why it appeared to work for you.
> 
> I would definitely just try using a non-& backgrounding method on the
> remote end, it'll be saner & quicker :)

Thank you Jeff for your helpful comments.

With above semi-confirmation I think I'll stay away from forking in-Fabric and 
will attempt handling things on remote end (as in start processes in 
background, noting PID, etc. etc. etc.) bit more scripting to push over to 
remote end, but I guess you stability/sanity doesn't come cheap ;)



> 
> -Jeff
-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout 
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330


-- 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---



reply via email to

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