[Twisted-web] spawning a xvfb and firefox with a timeout
Stephan
schenette at gmail.com
Mon Aug 22 16:45:52 EDT 2011
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, <exarkun at twistedmatrix.com> wrote:
> On 04:32 pm, schenette at gmail.com 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
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
More information about the Twisted-web
mailing list