Re: spawning a xvfb and firefox with a timeout

Stephan <[email protected]>
Newsgroups gmane.comp.python.twisted.web
Message-ID <CADozHMUCdw4V7pCvqRu70GyGa9CW2VEWZUc=+YaiNMYeCHOHBA@mail.gmail.com>
Hi Jean-Paul,

decorated with inlineCallbacks? why would I need that?

I'm trying to figure that out... but would it look like this?

        def killProcessIfAlive(self):
                logging.debug("killProcessIfAlive called")
                @defer.inlineCallbacks
                try:
                        yield self.transport.signalProcess('KILL')
                except error.ProcessExitedAlready:
                        logging.debug("process already exited")
                        pass

        def connectionMade(self):
                logging.debug("connection made timeout = %d", self.timeout)
                #@defer.inlineCallbacks
                def onTimer():
                        logging.debug("timeout triggered")
                        self.killProcessIfAlive()
                d = reactor.callLater(self.timeout, onTimer)


----
also I tried before you had sent out the email

os.kill(self.pid, SIGTERM)
and
os.kill(self.pid, SIGTERM)

but not

os.kill(-process.transport.pid, SIGTERM) (with the dash, does that
make a difference?)
On Mon, Aug 22, 2011 at 12:53 PM,  <[email protected]> wrote:
> On 04:32 pm, [email protected] wrote:
>>I think I might have figured out that you have to add usePTY=1 to
>>associate the process group, so that the children will be killed when
>>the parent process is killed.
>>e.g.
>>subprocess = reactor.spawnProcess(self.pp, args[0], args, env = os.e
>>nviron, usePTY=1)
>
> This is a not bad approach.  Another possibility might be to leave
> usePTY out but change how you kill the process.  There is the notion of
> "process groups", which contain one or more processes, and all of the
> processes in a group can be sent a signal by passing a negative number
> to os.kill.  For your case, the process group would probably be the same
> as the pid of the xvfb-run process, so you could do something like:
>
>    os.kill(-process.transport.pid, SIGTERM)
>
> Whether this is better or worse than using a PTY depends on the
> particulars of how xvfb-run manages its child process, whether it is
> okay to actually have a pty allocated, and probably some other POSIX
> arcana.
>>but I tried to separate out the killing in another process and now the
>>new method isnt' called.
>>are ProcessProtocol classes allowed to have other methods added to it
>>for calling?
>>
>>45     def killProcessIfAlive(self):
>>46         logging.debug("killProcessIfAlive called")
>>47         try:
>>48             yield self.transport.signalProcess('KILL')
>>49         except error.ProcessExitedAlready:
>>50             logging.debug("process already exited")
>>51             pass
>
> It looks like you wanted killProcessIfAlive to be decorated with
> inlineCallbacks, but I don't see that here.  So that would prevent the
> signal from ever actually being sent.  signalProcess doesn't return a
> Deferred though, so you can skip inlineCallbacks and the yield and that
> should also fix the problem.
>>52
>>53     def connectionMade(self):
>>54         logging.debug("connection made timeout = %d", self.timeout)
>>55         @defer.inlineCallbacks
>>56         def onTimer():
>>57             logging.debug("timeout triggered")
>>58             self.killProcessIfAlive()
>>59         d = reactor.callLater(self.timeout, onTimer)
>
> Ah, there's the inlineCallbacks.  It won't work there, though, it needs
> to go onto the generator function (the function that has yield in it).
>
> Jean-Paul
>
> _______________________________________________
> Twisted-web mailing list
> [email protected]
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.