about summary refs log tree commit diff
path: root/src/test/run-pass/thinlto
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2016-12-14 09:56:38 +0000
committerbors <bors@rust-lang.org>2016-12-14 09:56:38 +0000
commit01d53df82ef12625f947f5c0a6004e1aea2f9782 (patch)
tree7b1da9912098a376fa8ebbd6a78efb135ad29794 /src/test/run-pass/thinlto
parent5d3ec6b0a0f6f95412235dc5a6b5d416187a01f3 (diff)
parent5e991e0afb403fab6edfac096ecd5bb0190449ad (diff)
downloadrust-01d53df82ef12625f947f5c0a6004e1aea2f9782.tar.gz
rust-01d53df82ef12625f947f5c0a6004e1aea2f9782.zip
Auto merge of #38340 - alexcrichton:fix-travis, r=alexcrichton
Fix travis builds

After reading some articles [1] [2] yesterday about Docker and the "init"
process I got to thinking about the problems that we've been seeing on Travis.
The basic problem is that a Linux system may need an "init" process to work
properly when processes become zombies. Docker by default doesn't handle this
and the root process typically isn't an init process, so this can occasionally
cause quite a few problems.

We've been seeing spurious errors on Travis inside containers which look like
OOM and such, but my guess is that zombie processes were being reparented to the
top-level shell. The shell didn't expect the zombies and then behaved very
strangely.

This commit fixes these problems by using Yelp's "dumb-init" program [2] as the
init process in all of our containers. This ensures that there's a valid init
ready to reap children when they're reparented, which our test suite apparently
generates a bunch of throughout the tests and such.

[1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
[2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
Diffstat (limited to 'src/test/run-pass/thinlto')
0 files changed, 0 insertions, 0 deletions