[tor-bugs] #20030 [Obfuscation/meek]: meek-http-helper doesn't shutdown cleanly in 6.5a1

[Tor Bug Tracker & Wiki]

#20030: meek-http-helper doesn't shutdown cleanly in 6.5a1
------------------------------+---------------------
 Reporter:  arlolra           |          Owner:  dcf
     Type:  defect            |         Status:  new
 Priority:  Medium            |      Milestone:
Component:  Obfuscation/meek  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:                    |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+---------------------

Comment (by dcf):

 I tested compiling with various versions of Go and the earliest version
 that doesn't work is 1.6. 1.5.4 works, 1.6 doesn't.

 > Strangely enough, if I add `-log meek-client-torbrowser.log` after
 `meek-client-torbrowser` in Browser/TorBrowser/Data/Tor/torrc-defaults,
 then it kills the process cleanly.

 Here's what's going wrong: once it receives a signal, meek-client-
 torbrowser writes to its log as it shuts down. By default the log lines go
 to stderr. But meek-client-torbrowser's stderr is the same as its parent
 process's (tor's) stderr. Once tor terminates, trying to write to the log
 results in a SIGPIPE that kills meek-client-torbrowser before it can
 terminate its subprocesses.

 Why this only started happening with Go 1.6? See this
 [https://golang.org/doc/go1.6#minor_library_changes excerpt from the
 release notes]:
   On Unix-like systems, when a write to `os.Stdout` or `os.Stderr` (more
 precisely, an `os.File` opened for file descriptor 1 or 2) fails due to a
 broken pipe error, the program will raise a `SIGPIPE` signal. By default
 this will cause the program to exit; this may be changed by calling the
 `os/signal` `Notify` function for `syscall.SIGPIPE`. A write to a broken
 pipe on a file descriptor other 1 or 2 will simply return `syscall.EPIPE`
 (possibly wrapped in `os.PathError` and/or `os.SyscallError`) to the
 caller. The old behavior of raising an uncatchable `SIGPIPE` signal after
 10 consecutive writes to a broken pipe no longer occurs.

 That's why logging to a file avoided the error: the output pipe was no
 longer being broken.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20030#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online