Print a warning when --sandbox_debug is in use (to prevent sandbox directories from piling up)

Description of the problem / feature request:

Trying to figure out why bazel clean --expunge seemed to hang I discovered that Bazel had created hundreds, (actually tens of thousands) of sandboxes in /private/var/tmp/…etc… Each of which seems to contain a copy of all my externals, e.g. the entire Android SDK and NDK. I’m now running rm -rfv on those and it’s taking a long time.

It would be nice if this didn’t happen. I’m assuming a workaround is to run expunge regularly, maybe once a day? Maybe a note should be added to the documentation about this. Also, presumably a new version might do things differently, so maybe the install instructions should start with a recommendation to run bazel clean --expunge before upgrading?

Feature requests: what underlying problem are you trying to solve with this feature?

Sometimes I need to expunge, since some out-of-date artifacts seem to get left in the output. Or maybe I don’t need to, but I do anyway just to play it safe. I had given up on this when expunge started taking over 1/2 hour.

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Run bazel over the course of several months/upgrades?

What operating system are you running Bazel on?

Mac OS 10.12.6

What’s the output of bazel info release?

release 0.13.0

What’s the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

$ git remote get-url origin ; git rev-parse master ; git rev-parse HEAD fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git

Have you found anything relevant by searching the web?

No

[mobileink]

On Sun, Jun 24, 2018, 4:46 PM Gregg Reynolds [e-mail] wrote:

On Sun, Jun 24, 2018, 4:37 PM Philipp Wollermann [e-mail] wrote:

Could you please check if you’re using the flag --sandbox_debug (maybe in your ~/.bazelrc)?

Yep. I pretty much always so that.

In almost all cases where this issue was reported, users were using this flag (usually accidentally left over from debugging an issue some time ago). If you use the flag, Bazel keeps the sandbox directories around so that users / devs can inspect their contents.

If the flag is not used, Bazel deletes sandbox directories as soon as the action that used them has finished and then once the build is over, it deletes the entire sandbox base directory https://source.bazel.build/bazel/+/88d1caeef07533429468515f63b3d4e2cb9a7a80:src/main/java/com/google/devtools/build/lib/sandbox/SandboxModule.java;l=323, so what you’re seeing here should not happen. In case it cannot delete the sandbox directories, it will print a warning message during the build saying: "Failed to delete sandbox base: ". Have you seen that?

Nope.

What you describe makes sense to me. If you tend to use --sandbox_debug you should do a little expunging once in a while. I think the “fix” is just a little more documentation. Or maybe that info is there and I just didn’t see it. 😉

Maybe better, since nobody reads documentation: when --sandbox_debug is used, print some kind of terrifying warning to alert the user to the side-effect of leftover stuff. Not sure what it should say, maybe something like “when you’re done with sandbox_debug you should prolly expunge”?

Thanks!

[jin]

@philwo are you still intending to work on this? If not, could you reassign or unassign to reflect the current status?