Do not redirect stderr of Apache process

Do not redirect stderr of Apache process

Apache gets stuck when the pipe connected to stderr gets filled up and
not read. This patch makes stderr of apache directly goes to build log.

BUG=30536, 431172
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=185164

[Kunihiko Sakamoto, 2014-11-11 04:59:25]

Patchset #2 (id:20001) has been deleted

[Kunihiko Sakamoto, 2014-11-11 04:59:36]

Patchset #1 (id:1) has been deleted

[Kunihiko Sakamoto, 2014-11-11 05:48:52]

Patchset #1 (id:40001) has been deleted

[Kunihiko Sakamoto, 2014-11-11 05:57:15]

ksakamoto@chromium.org changed reviewers:
+ dpranke@chromium.org

[Kunihiko Sakamoto, 2014-11-11 05:57:16]

PTAL

This is in preperation for disabling AcceptEx on win apache
(https://codereview.chromium.org/695193006/).
Without this, apache fails to start:
https://code.google.com/p/chromium/issues/detail?id=431172#c6

[Dirk Pranke, 2014-11-11 16:31:53]

lgtm.

https://codereview.chromium.org/712253002/diff/60001/Tools/Scripts/webkitpy/l...
File Tools/Scripts/webkitpy/layout_tests/servers/apache_http.py (right):

https://codereview.chromium.org/712253002/diff/60001/Tools/Scripts/webkitpy/l...
Tools/Scripts/webkitpy/layout_tests/servers/apache_http.py:132: raise
server_base.ServerError('Failed to start %s: %s' % (self._name, retval))
This change worries me. I fairly strongly recall that there were cases where
Apache did actually fail to start up properly but didn't return a nonzero error
code.

However, I can see how opening a pipe and never reading from it might cause
problems also.

I guess we can try this for now. If we see issues, we'll probably need to change
the code to launch a thread to read from the pipe to ensure that we don't get
the blocking you've seen.

[Kunihiko Sakamoto, 2014-11-12 01:02:39]

https://codereview.chromium.org/712253002/diff/60001/Tools/Scripts/webkitpy/l...
File Tools/Scripts/webkitpy/layout_tests/servers/apache_http.py (right):

https://codereview.chromium.org/712253002/diff/60001/Tools/Scripts/webkitpy/l...
Tools/Scripts/webkitpy/layout_tests/servers/apache_http.py:132: raise
server_base.ServerError('Failed to start %s: %s' % (self._name, retval))
On 2014/11/11 16:31:53, Dirk Pranke wrote:
> This change worries me. I fairly strongly recall that there were cases where
> Apache did actually fail to start up properly but didn't return a nonzero
error
> code.
> 
> However, I can see how opening a pipe and never reading from it might cause
> problems also.
> 
> I guess we can try this for now. If we see issues, we'll probably need to
change
> the code to launch a thread to read from the pipe to ensure that we don't get
> the blocking you've seen.

Got it. Let's try this for now.

[Kunihiko Sakamoto, 2014-11-12 01:02:43]

The CQ bit was checked by ksakamoto@chromium.org

[commit-bot: I haz the power, 2014-11-12 01:03:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/712253002/60001

[commit-bot: I haz the power, 2014-11-12 01:50:13]

Committed patchset #1 (id:60001) as 185164