Server not daemonized correctly on Windows

[sgreenstein]

Description of the problem / feature request / question:

On Windows when running a bazel command that also starts the bazel server via certain means other than the command line, the command doesn't stop as it should. Examples include: running a build on a remote Windows box over cygwin ssh, Visual Studio invoking a build, and invoking a bazel command with python's subprocess.check_output.

If possible, provide a minimal example to reproduce the problem:

In a Bazel workspace:

C:\Users\sgreens\bazel\bazel>bazel shutdown
...............

C:\Users\sgreens\bazel\bazel>python
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output(['bazel', 'info'])
...............
____Loading package: @bazel_tools//tools/jdk
____Loading package: @local_config_xcode//
____Loading package: @local_config_cc//
____Loading package: @local_jdk//

It hangs at the above. When I then run bazel shutdown in a different command prompt, it prints the output of the command and gives me back the python prompt:

'bazel-bin: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/execroot/io_bazel/bazel-out/msvc_x64-fastbuild/bin\nbazel-genfiles: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/execroot/io_bazel/bazel-out/msvc_x64-fastbuild/genfiles\nbazel-testlogs: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/execroot/io_bazel/bazel-out/msvc_x64-fastbuild/testlogs\ncharacter-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1\ncommand_log: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/command.log\ncommitted-heap-size: 417MB\nexecution_root: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/execroot/io_bazel\ngc-count: 4\ngc-time: 64ms\ninstall_base: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/install/32a84c5d00ffe54b8987b07265bf4f39\njava-home: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/install/32a84c5d00ffe54b8987b07265bf4f39/_embedded_binaries/embedded_tools/jdk/jre\njava-runtime: OpenJDK Runtime Environment (build 1.8.0_144-b01) by Azul Systems, Inc.\njava-vm: OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode) by Azul Systems, Inc.\nmax-heap-size: 7621MB\nmessage_log: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/message.log\noutput_base: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp\noutput_path: C:/users/sgreens/appdata/local/temp/_bazel_sgreens/u4t0fakp/execroot/io_bazel/bazel-out\npackage_path: %workspace%\nrelease: release 0.6.1\nserver_pid: 21308\nused-heap-size: 47MB\nworkspace: C:/users/sgreens/bazel/bazel\n'
>>>

Environment info

• Operating System: Windows 10

• Bazel version (output of bazel info release): 0.6.1

Anything else, information or logs or outputs that would be helpful?

The above repro does not work on Linux.
Additionally, everything works as expected when calling bazel with python's subprocess.call or check_call (as opposed to check_output above)

[laszlocsomor]

Awesome bug report, thank you!

@meteorcloudy : Is this something you could perhaps take a look at?

[meteorcloudy]

Interesting, let me take a look at this.

[meteorcloudy]

I believe bazel client pass a pipe handle for stdout to bazel server, so python waits as long as the server holds the handle. This doesn't happend to stderr though, I am starting to look at the code for reasons.

[meteorcloudy]

I found it's the same root cause for #2182 and #2248

I'll send a fix