[sos-devel] [RFC] wrap commands in /usr/bin/timeout when available

Jesse Jaggars jjaggars at redhat.com
Tue Mar 20 18:21:39 UTC 2012


On Tue, Mar 20, 2012 at 05:49:14PM +0000, Bryn M. Reeves wrote:
> On 03/20/2012 05:44 PM, Adam Stokes wrote:
> > If timeout is set with this application does it give control back to 
> > sosreport if sending a TERM fails to stop the process? If not, we would 
> > need to investigate some asynchronous way to handle those cases in which 
> > case my proposed solution may resolve that.
> 
> Yes - timeout effectively runs the child as a daemon which detaches from
> the controlling process/terminal and then allows the parent to escape
> the clutches of whatever dragged the child into the swamp.
> 
> Regards,
> Bryn.
> 

Using `timeout` is great for our situation since it allows us to offer a
shell to plugins (for easy pipelines). Also, there isn't much extra overhead
since we are forking from python anyways.

The only major downside is that we will rely on the binary to implement
the timeout mechanism for us. This means that we either have to
implement alternative timeout methods for platforms that lack `timeout`
or fail to supply a timeout on those platforms. This is no worse than we
do today, so it's not much of a downside I don't suppose.

Given that we will likely want to try to provide an alternative timeout
method we should probably plan to plug in different implementations
somehow. Currently the method to fork a subprocess and do some work is
just a thin wrapper around subprocess.Popen. It would make sense to
allow a Policy object to override this implementation, though that might
be overkill for now since we can see if `timeout` exists and use it or
just do what we do now and hope for the best.

Just some thoughts...

Jesse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/sos-devel/attachments/20120320/4f7a09f7/attachment.sig>


More information about the sos-devel mailing list