Re: Review Request 67137: Avoided leaking file descriptors in Mesos containerizer.

[Mesos Reviewbot <re...@mesos.apache.org>]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67137/#review204165
-----------------------------------------------------------



Patch looks great!

Reviews applied: [67398, 67137]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On May 24, 2018, 11:13 a.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67137/
> -----------------------------------------------------------
> 
> (Updated May 24, 2018, 11:13 a.m.)
> 
> 
> Review request for mesos, Gilbert Song, Jie Yu, and James Peach.
> 
> 
> Bugs: MESOS-8917
>     https://issues.apache.org/jira/browse/MESOS-8917
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This patch explicitly closes not required file descriptors when
> forking a Mesos containerizer instance. We currently only pass on
> stdin, stout, and sterr.
> 
> While it would in principle be possible to open all file descriptors
> with `O_CLOEXEC`, this is not practical as
> 
> * `O_CLOEXEC` is not supported on BSDs (not Windows either, but file
>   descriptor leaks are prevented there in a different way), and
> * we might call thirdparty code outside of our control which does not
>   use e.g., `O_CLOEXEC` either (the case e.g., for leveldb).
> 
> Closing all file descriptors after the fork avoids leaks even in above
> scenarios.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/mesos/launch.cpp cec6558d0ac61bf0fec87d2e101e8f84730a765a 
> 
> 
> Diff: https://reviews.apache.org/r/67137/diff/9/
> 
> 
> Testing
> -------
> 
> `make check`
> 
> I still need to confirm this patch in CI on a wider range of scenarios.
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>