From 6446607f6eb2ce2b1ff5e5d8d429456dcdfec01f Mon Sep 17 00:00:00 2001 From: Googler Date: Fri, 2 Jun 2023 13:36:01 -0700 Subject: [PATCH] Improve documentation on the blaze archive extraction. PiperOrigin-RevId: 537397370 Change-Id: Ied5b9c7591f10e61e48b95157e61a29a825d7389 --- site/en/run/client-server.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/site/en/run/client-server.md b/site/en/run/client-server.md index 22a88af1eef98e..0f2ce15aa65dfb 100644 --- a/site/en/run/client-server.md +++ b/site/en/run/client-server.md @@ -17,17 +17,24 @@ based on the output base, which by default is determined by the path of the base workspace directory and your userid, so if you build in multiple workspaces, you'll have multiple output bases and thus multiple Bazel server processes. Multiple users on the same workstation can build concurrently in the same -workspace because their output bases will differ (different userids). If the -client cannot find a running server instance, it starts a new one. The server -process will stop after a period of inactivity (3 hours, by default, which can -be modified using the startup option `--max_idle_secs`). - -For the most part, the fact that there is a server running is invisible to the -user, but sometimes it helps to bear this in mind. For example, if you're -running scripts that perform a lot of automated builds in different directories, -it's important to ensure that you don't accumulate a lot of idle servers; you -can do this by explicitly shutting them down when you're finished with them, or -by specifying a short timeout period. +workspace because their output bases will differ (different userids). + +If the client cannot find a running server instance, it starts a new one. It +does this by checking if the output base already exists, implying the blaze +archive has already been unpacked. Otherwise if the output base doesn't exist, +the client unzips the archive's files and sets their `mtime`s to a date 9 years +in the future. Once installed, the client confirms that the `mtime`s of the +unzipped files are equal to the far off date to ensure no installation tampering +has occurred. + +The server process will stop after a period of inactivity (3 hours, by default, +which can be modified using the startup option `--max_idle_secs`). For the most +part, the fact that there is a server running is invisible to the user, but +sometimes it helps to bear this in mind. For example, if you're running scripts +that perform a lot of automated builds in different directories, it's important +to ensure that you don't accumulate a lot of idle servers; you can do this by +explicitly shutting them down when you're finished with them, or by specifying +a short timeout period. The name of a Bazel server process appears in the output of `ps x` or `ps -e f` as bazel(dirname), where _dirname_ is the basename of the